Configurations, again…

Hi

I'm once again banging my head against the wall that is our
configuration system.

First, I have an attribute #trackingStrategy in
WARegistryConfiguration that defines as the only option a query field
strategy. I have the same attribute again in
WAApplicationConfiguration having many more options like cookie based.
However in the configuration editor only the options from
WARegistryConfiguration show up. Is this supposed to work? To me the
code is incomprehensible and undebuggable.

Second, what I want is an instance from a list of classes. This
doesn't really seem to be supported. I could just #collect: #new but
then I have to implement #= to only compare the class names. Any
suggestions?

Third, WAUserConfigurationEditorVisitor >> #visitListAttribute: always
sends #beOptional. I don't want to have the option to select nil.
Looking at the other configurations #serverProtocol in
WARequestHandlingConfiguration seems to be the only one for which nil
makes sense. Wouldn't it be better to make the list not optional and
if you want to allow nil you have to include it in the options
explicitly?

Fourth, I really believe our configuration system is way too complex
and slow as a result (which matters because creating a URL as to look
up #serverPath and friends). As a first simplification step, does a
configuration really need multiple parents? Couldn't we get away with
just one?

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/16 Philippe Marschall <[hidden email]>:
Ok, so here's a proposal to simplify it to what we really need. The
thing that IMHO is unnecessarily complex and needs to be simplified is
the value look up.

We split SystemConfiguration and WAUserConfiguration.
SystemConfiguration is just a factory for a
WAConfigurationDescription. They are stateless and there's no need for
them to be singletons. They have only one parent. Since their
hierarchy matches the class hierarchy (WAApplication is a subclass of
WARegistry) that should work fine. We can even get rid of #parents at
all and directly use subclassing.

WAUserConfiguration is where the actual values are stored. To avoid
confusion the classes get renamed to WAUserConfigurationStore and
WASharedConfigurationStore. WAUserConfigurationStore and
WASharedConfigurationStore have no parent the only difference is that
WASharedConfigurationStore has a name. They have two instance
variables, an identity dictionary mapping symbols to values and the
configuration instance. When they are instantiated the configuration
instance is used to populate all values with defaults (we probably
need to store a value holder to find out whether we found nil or
nothing). A look up simply goes to this dictionary. If it the look up
fails the configuration is checked whether the attribute was added in
the mean time (this is optional).
There is a third class WAInheritableUserConfigurationStore that has a
single parent which is a WASharedConfigurationStore. It has also a
reference to it's configuration instance and the same identity
dictionary for values. When they're instantiated the their values are
not instantly populated with default values, instead the parent acts
like a prototype in JavaScript. Look up first happens in the object
itself, then looks into the parent and only if that fails as well uses
the configuration to store a default value.

This brings our look up down to just two identity dictionaries that
map key to value. This would make the code simpler, easier to
understand, easier to debug and faster.

A session has the same configuration store object as the application
(there are currently no senders of #configuration in WASession, there
is currently no WASessionConfiguration, there is currently no way to
configure anything on WASession).

Attribute expressions go away, so do search contexts.

Is there any use case that's is currently used and not supported with
this approach?

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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. 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). 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?

Julian

On Sat, Jul 16, 2011 at 5:26 PM, Philippe Marschall
<[hidden email]> wrote: _______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/18 Julian Fitzell <[hidden email]>:
> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Sunday, July 24, 2011 3:39:06 AM
| Subject: Re: [Seaside-dev] Configurations, again…
|
| 2011/7/18 Julian Fitzell <[hidden email]>:
| > 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
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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. 
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev