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. <div>
<br></div><div>The 'optimization' in WAUserConfiguration>>at:put: drives me completely crazy because it caused the 2nd load of Seaside to fail on VA Smalltalk in WAWallkbackErrorHandler>>initialize. Then I noticed that some other components 'protect' themselves against this problem by keeping track of whether or not they have set a configuration attribute rather than simply al trying to set the attribute. There is some secret protocol here that I haven't figured out yet.</div>
<div><br></div><div>So, my bottom line is that the configuration support does not pass the 'simplest thing that can possibly work' test. If the current complexity is really needed (as shown by use cases), then we should figure out how to layer the complex solution (for those who need it) on top of a basic solution (for the rest of us).<div>
<br clear="all">John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br>Skype: john_okeefe2 Mobile: +1 919 417-3181 (Business hours USA Eastern Time zone (GMT -5))<br><a href="mailto:john_okeefe@instantiations.com" target="_blank">john_okeefe@instantiations.com</a><br>
<a href="http://www.instantiations.com/" target="_blank">http://www.instantiations.com</a><br><em><strong>VA Smalltalk...Onward and Upward!</strong></em><br>
<br><br><div class="gmail_quote">On Fri, Sep 2, 2011 at 1: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>
<br>
Dale<br>
<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>
</blockquote></div><br></div></div>