Re: [Seaside-dev] Configurations, again…

[John O'Keefe]

I can only second Dale's comments (I'm glad Phillipe has trouble with
configurations also or I would suspect it is only us 'gray hairs' who can't
figure it out). When the cache gets out of wack, it can take forever to
figure out how to get things fixed.

The 'optimization' in WAUserConfiguration>>at:put: drives me completely
crazy because it caused the 2nd load of Seaside to fail on VA Smalltalk in
WAWallkbackErrorHandler>>initialize.  Then I noticed that some other
components 'protect' themselves against this problem by keeping track of
whether or not they have set a configuration attribute rather than simply al
trying to set the attribute.  There is some secret protocol here that I
haven't figured out yet.

So, my bottom line is that the configuration support does not pass the
'simplest thing that can possibly work' test. If the current complexity is
really needed (as shown by use cases), then we should figure out how to
layer the complex solution (for those who need it) on top of a basic
solution (for the rest of us).

John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
Skype: john_okeefe2     Mobile:  +1 919 417-3181 (Business hours USA Eastern
Time zone (GMT -5))
john_okeefe at instantiations.com
http://www.instantiations.com
*VA Smalltalk...Onward and Upward!*


On Fri, Sep 2, 2011 at 1:47 PM, Dale Henrichs <dhenrich at vmware.com> wrote:

> I concur that configuration system is too complex ... For the most part
> I've figured that I am just not smart enough to understand the model, but if
> I'm not the only one that is confused, perhaps a simpler model _is_ called
> for...
>
> I don't doubt that the current system allows one to do some pretty fancy
> configurations, but if folks don't understand the system, then perhaps
> rethinking tis called for ... Better tools and API support for doing things
> simply should be added if the underlying model isn't going to change.
>
> During ESUG, I (again) ran into the issue where the cache state was messed
> up in a user's image and I was unable to get the state reset correctly (due
> to the fact that resetting the singleton isn't enough if some poor soul has
> still got his hands on the stale puppy?) ... If I had several hours to dig
> into the code again, I am certain that I could have figured out the magic,
> but .... It would have been nice if there was an explicit mechanism for
> resetting Seaside to a known state ....
>
> Again it could just be my ignorance, but the tools don't make the job of
> managing the configuration any simpler ... I always wonder what state goes
> away when I nuke the "shared tools config thingy" to get rid of the
> development tool bar ...
>
> I assume the caching issue was due to a bug, but the lack of a way to reset
> the system to a known state, made the bug much more annoying that it needed
> to be ...
>
> Dale
>
>
> ----- Original Message -----
> | From: "Philippe Marschall" <philippe.marschall at gmail.com>
> | To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
> | Sent: Sunday, July 24, 2011 3:39:06 AM
> | Subject: Re: [Seaside-dev] Configurations, again…
> |
> | 2011/7/18 Julian Fitzell <jfitzell at gmail.com>:
> | > Let me try to get my head back into this and think about it...
> | >
> | > Off the top of my head, it seems like having multiple parents is
> | > essential to allow addons to support custom attributes for a
> | > request
> | > handler.
> |
> | Does anybody use this? In addition I would assume that every time you
> | do
> | WAAdmin clearConfigurationCaches
> | they would manually have to be "reinstalled".
> |
> | > I'm not a big fan of using subclassing any more than
> | > necessary and the parents are a form of delegation.
> | >
> | > I also don't understand why you're talking about using classes
> | > instead
> | > of singletons (at least that's what I think you're suggesting).
> |
> | Subclassing is the natural way to model specialization in Smalltalk.
> | When WAApplication is a subclass of WARegistry I would expect
> | WAApplicationConfiguration be a subclass of WARegistryConfiguration.
> | Otherwise when does WAApplicationConfiguration have to have a parent
> | of WARegistryConfiguration? Always? Sometimes?
> |
> | Also subclassing makes it easier to customize the descriptions. For
> | example I can just subclass and override #libraryClasses. I don't
> | have
> | to copy and paste the whole attribute definition. The code is also
> | easier to debug, there is no custom multiple inheritance which
> | multiple parents where I don't know what takes precedence over what.
> | It's just Smalltalk method look up rules which everyone is familiar
> | with.
> |
> | The singletons introduce a "deploy" cycle, every time you change a
> | configuration you have to "redeploy" (reset the singleton).
> |
> | And singletons suck.
> |
> | > In
> | > this case, even if there was no other reason to avoid that (which I
> | > think there is), those classes share behaviour with the user
> | > configurations, don't they?
> |
> | No, not at all. The WA*RequestHandlerClass*Configuration would just
> | be
> | description factories through the #describeOn: method. The user
> | configuration would just store the configuration values. There would
> | be no overlap at all between the two.
> |
> | Cheers
> | Philippe
> | _______________________________________________
> | seaside-dev mailing list
> | seaside-dev at lists.squeakfoundation.org
> | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> |
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20110903/e93e5754/attachment-0001.htm