Re: [Seaside-dev] Configurations, again…

[Julian Fitzell]

I still don't think it's very complicated, but clearly there's no point me
arguing that over and over again with others who think it is. :) And the
caching - well that's all been added after the fact.

Philippe and I discussed this at ESUG a bit, and my suggestion was to first
extract the lookup code from the model - that would leave a very simple and
easy to understand model, with a no-less-complex but at least
not-muddled-with-the-model algorithm. If we then choose to change the way
lookup works as well, so be it, but I'd rather try to fix the immediate
problem of understandability first before totally reworking the behaviour...

Julian

On Fri, Sep 2, 2011 at 6: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/749ad2dc/attachment.htm