we would like to group settings in a logical way, like
RequestCycleSettings
PageSettings
SessionSettings
etc
and we would like to do so in a very consistent way. that means we get rid of all the convinience functions weve been adding to the application object like newCrypt() and filterResponse() and replace them with factory interfaces that can be pushed into the appropriate settings object.
so when this is done the application object will have getName() and get....Settings() - thats it.
the only problem with this is that sometimes it makes sense to have a setting in two or more settings objects. to solve this we propose to create a monolithic settings object and let setting-categories be interfaces onto this settings object. this will allow us to easily share settings between categories by implementing the same getter/setters in two or more interfaces. we can reuse the existing ApplicationSettings object as our monolithic settings store.
so the work involved would be:
merge ApplicationPages into ApplicationSettings
create factory interfaces for overridable things in the Application object and move the functionality into an implementation of the factory interface. add setters/getters for the interfaces to ApplicationSettings
create the category interfaces for the ApplicationSettings object.
pros:
consistency
application object is clean
it will be easier to find things
the different settings interfaces will make it easier for newbies to find what they are looking for and to browse available settings
cons:
its a bit more work to override certain settings because someitmes you will need to implement a factory interface as opposed to just overriding a method.
how does this sound?
-Igor
On 1/1/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
factories and strategies in Application. Only simply (integer, string,
boolean) in AppsSettings. But that is just my opinon.
Juergen
On 1/1/06, Jonathan Locke < [EMAIL PROTECTED]> wrote:
>
> factories and strategies too?
>
> Juergen Donnerstag wrote:
> > I agree that it is not always clear where to find it but at the end
> > there are only two (three) possibilities. I don't like the idea of a
> > giant application class. I still like the original intent: easy
> > (integer, string, boolean) parameters in ApplicationSettings and more
> > complex parameters like factories in Application.
> >
> > Juergen
> >
> > On 1/1/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> >
> >> Maybe we should get rid of ApplicationSettings and ApplicationPages
> >> entirely and just have one gigantic Application class. It's a little
> >> ugly, but at least you know where to look for things!
> >>
> >> My original intent with this class was to just put all the simple values
> >> in a settings class. But now we've got strategies and other complex
> >> objects in there and I'm not sure users are going to be able to make any
> >> logical sense of the division anyway.
> >>
> >> What's your vote? I think I'm +1, but I could be convinced to change my
> >> mind.
> >>
> >> Best,
> >>
> >> Jon
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> >> for problems? Stop! Download the new AJAX search engine that makes
> >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> >> _______________________________________________
> >> Wicket-develop mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
