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.<br><br>
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...<br>
<br>Julian<br><br><div class="gmail_quote">On Fri, Sep 2, 2011 at 6:47 PM, Dale Henrichs <span dir="ltr"><<a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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...<br>
<br>
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.<br>
<br>
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 ....<br>
<br>
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 ...<br>
<br>
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 ...<br>
<font color="#888888"><br>
Dale<br>
</font><div><div></div><div class="h5"><br>
<br>
----- Original Message -----<br>
| From: "Philippe Marschall" <<a href="mailto:philippe.marschall@gmail.com">philippe.marschall@gmail.com</a>><br>
| To: "Seaside - developer list" <<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a>><br>
| Sent: Sunday, July 24, 2011 3:39:06 AM<br>
| Subject: Re: [Seaside-dev] Configurations, again…<br>
|<br>
| 2011/7/18 Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>>:<br>
| > Let me try to get my head back into this and think about it...<br>
| ><br>
| > Off the top of my head, it seems like having multiple parents is<br>
| > essential to allow addons to support custom attributes for a<br>
| > request<br>
| > handler.<br>
|<br>
| Does anybody use this? In addition I would assume that every time you<br>
| do<br>
| WAAdmin clearConfigurationCaches<br>
| they would manually have to be "reinstalled".<br>
|<br>
| > I'm not a big fan of using subclassing any more than<br>
| > necessary and the parents are a form of delegation.<br>
| ><br>
| > I also don't understand why you're talking about using classes<br>
| > instead<br>
| > of singletons (at least that's what I think you're suggesting).<br>
|<br>
| Subclassing is the natural way to model specialization in Smalltalk.<br>
| When WAApplication is a subclass of WARegistry I would expect<br>
| WAApplicationConfiguration be a subclass of WARegistryConfiguration.<br>
| Otherwise when does WAApplicationConfiguration have to have a parent<br>
| of WARegistryConfiguration? Always? Sometimes?<br>
|<br>
| Also subclassing makes it easier to customize the descriptions. For<br>
| example I can just subclass and override #libraryClasses. I don't<br>
| have<br>
| to copy and paste the whole attribute definition. The code is also<br>
| easier to debug, there is no custom multiple inheritance which<br>
| multiple parents where I don't know what takes precedence over what.<br>
| It's just Smalltalk method look up rules which everyone is familiar<br>
| with.<br>
|<br>
| The singletons introduce a "deploy" cycle, every time you change a<br>
| configuration you have to "redeploy" (reset the singleton).<br>
|<br>
| And singletons suck.<br>
|<br>
| > In<br>
| > this case, even if there was no other reason to avoid that (which I<br>
| > think there is), those classes share behaviour with the user<br>
| > configurations, don't they?<br>
|<br>
| No, not at all. The WA*RequestHandlerClass*Configuration would just<br>
| be<br>
| description factories through the #describeOn: method. The user<br>
| configuration would just store the configuration values. There would<br>
| be no overlap at all between the two.<br>
|<br>
| Cheers<br>
| Philippe<br>
| _______________________________________________<br>
| seaside-dev mailing list<br>
| <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
| <a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
|<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br>