Where do people store their own application-level attributes?
#myDbLocation, for example? This is such a basic question for every web app, I'm surprised tto find he answer so elusive.. I was looking at WAApplication>>#preferenceAt: and #preferenceAt:put:. Even though DB Location is a property, not "preference" I thought it would at least work.. Nope. #preferenceAt: goes through its WAUserConfiguration's specific set of "attributes", which I have not yet figured out how to extend.. .. and I'm not sure I would want to because access to those attributes is very inefficient -- creating a temporary IdentityDictionary and IdentitySet, enumerating all "ancestors" and each ancestor enumerating its "localAttributes" while adding and checking the IdentitySet in an inefficient way too.. Maybe I don't need efficient access, not sure yet, but I was really just looking for a properties Dictionary I could use; simple, fast and unrestricted... That's what I thought the #preferenceAt: was. Now I see besides #attributeAt:, WAConfiguration also has #at:,.... but its not obvious what it is doing. Do I need to define my own subclass of WAConfiguration to do this? Any advice is appreciated.. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Chris,
There’s not much documentation on the WAConfiguration framework. I don’t really know about applications really using this infrastructure. Some Seaside extensions (such as Seaside-Gettext) use it. If you want to use Seaside’s WAConfiguration framework to embed your application-specific settings: - The class comment in WASystemConfiguration provides useful information. - Take a look at an example class: WAEmailConfiguration - When you register an application, here’s what it needs to add the configuration: application preferenceAt: #smtpServer put: ’smtp.somewhere.com'. application configuration addParent: WAEmailConfiguration instance. Preference values are cached once looked up in an application. So, that should cover performance concerns with the lookup. Hope this helps, Johan > On 19 Nov 2015, at 21:57, Chris Muller <[hidden email]> wrote: > > Where do people store their own application-level attributes? > #myDbLocation, for example? This is such a basic question for every > web app, I'm surprised tto find he answer so elusive.. > > I was looking at WAApplication>>#preferenceAt: and #preferenceAt:put:. > Even though DB Location is a property, not "preference" I thought it > would at least work.. > > Nope. #preferenceAt: goes through its WAUserConfiguration's specific > set of "attributes", which I have not yet figured out how to extend.. > > .. and I'm not sure I would want to because access to those attributes > is very inefficient -- creating a temporary IdentityDictionary and > IdentitySet, enumerating all "ancestors" and each ancestor enumerating > its "localAttributes" while adding and checking the IdentitySet in an > inefficient way too.. > > Maybe I don't need efficient access, not sure yet, but I was really > just looking for a properties Dictionary I could use; simple, fast and > unrestricted... That's what I thought the #preferenceAt: was. > > Now I see besides #attributeAt:, WAConfiguration also has #at:,.... > but its not obvious what it is doing. > > Do I need to define my own subclass of WAConfiguration to do this? > Any advice is appreciated.. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |