[Seaside-dev] Re: Configurations, again…

[Philippe Marschall]

2011/7/16 Philippe Marschall <philippe.marschall at gmail.com>:
> 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?

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