Re: [Seaside-dev] Configurations, again…

[Julian Fitzell]

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
<philippe.marschall at gmail.com> wrote:
> 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
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>