Well, you're getting at it, but what I want is for the scope to apply to all instances of that component, for that application instance only, hence needing to store it at application level, i.e. in the configuration. Everything else you suggested would provide innappropriate scope. Basically, I need the level just above session, application. Configuration provides that, but not without pre creating it, no biggie, I'll just tuck a dictionary into a predefined slot in a configuration variable, I was just suprised to not find this already an option.

________________________________

From: seaside-bounces@lists.squeakfoundation.org on behalf of Julian Fitzell Sent: Sat 12/31/2005 12:19 AM To: The Squeak Enterprise Aubergines Server - general discussion. Subject: Re: [Seaside] Configuration

Well,

You can just add an instance variable to the component, optionally marking it for backtracking (or using a holder) if appropriate. Or, if it applies to all instances of that component, use a class variable. Or, if it applies only within one session, store it as an instance method on a custom session class and access it from there within the component.

Does that answer the question or am I misunderstanding it?

Julian

Ramon Leon wrote:

Hi, I'm trying to store some dynamic configuration data and having some problem figuring out how. Is there a way to store application level configuration data, say a component remembering some settings, without having to predefine a special configuration class? This data doesn't need to be seen or edited on the configuration screen, I just want a hash to stick component specific data dynamically. _______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jan 2, 2006, at 4:58 PM, Julian Fitzell wrote:

Well, you used to be able to subclass Application but I have a feeling this was deprecated in favour of subclassing session and renderloop... The new configuration stuff never really got fully fleshed out...

So the 2.5 configuration stuff was being reworked for 2.6, but is somewhat stalled? Or is that not really going to be a feature in 2.6?

I never used the 2.5 stuff, but now I would like to ;)

Brian

On Jan 12, 2006, at 9:13 AM, Julian Fitzell wrote:

The inheritance was there but we never really got to the file part and never had a good UI for dealing with these inherited properties so it never got used. Avi was talking about stripping down the inheritance model and making it simpler but to be honest I'm not sure where, if anywhere, that got to.

The latest versions of Seaside 2.6 do have the stripped down model. Effectively what's gone is the user-entered site-wide defaults; you can have as many levels of programmatic defaults in the code as you like, but you only get to manually override at the application level.

Note the "programmatic" - one thing that works fairly well for site- wide defaults is to have code in a SystemConfiguration subclass that looks at its environment (for example, what working directory the image is in or the contents of some files) and sets the defaults accordingly. What I've found myself doing is having those programmatic defaults get used in the production environment, and then using app-level overrides in the development environment which doesn't have all the right config files etc around.

Avi