I wouldn't want Wicket to wait on our book... hell, the webwork guys
took 1.5 years to complete the book... :)... Not that we intent to
take that long.
And for the record: we haven't written about application settings yet.
Just put the changes in 1.2, I'm fine with that. so +1 on the proposal
you and Igor cooked up. Please put out a new vote for that (perhaps
take it to the users list, and tell it will break stuff). The users
should have a vote in this (though not binding).
Martijn
On 1/1/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
> we could do that, but i think these settings are a major usability issue
> and i'm fine with changing under 1.3 or 2.0 or whatever, but i'd be
> concerned that the book won't have this nice grouping of settings then.
> it's all going to be a lot easier to swallow this way...
>
> have you and eelco done much writing on application settings? if not,
> this is definitely the time to get this done...
>
> Martijn Dashorst wrote:
> > -1 on a 2.0... It is still minor enough for a .x release, not a major.
> > I /am/ concerned with the creeping scope of the 1.2 release. We have
> > been talking several times about doing more, minor releases more
> > often. Currently it sounds like we're building a huge release again.
> >
> > I'd say stop with adding features or refactor stuff, finalize 1.2 and
> > either move into 2.0 or 1.3, but quit stalling this 1.2 thing.
> >
> > BTW I think we already broke drop-in compatibility with 1.1 and 1.0
> > for that matter.
> >
> > Martijn
> >
> >
> > On 1/1/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> >
> >> okay, maybe also getApplicationSettings() and
> >>
> >> IApplicationSettings
> >> {
> >> classResolver
> >> unexpectedExceptionDisplay
> >> }
> >>
> >> these are more application related than request-cycle related.
> >>
> >> and defaultLocale belongs under ISessionSettings as well as
> >> IResourceSettings
> >> and localizer obviously belongs under IResourceSettings, not
> >> IMarkupSettings
> >>
> >> overall, looks pretty good... more manageable and more evolvable.
> >>
> >> Jonathan Locke wrote:
> >>
> >>> i'm +1
> >>>
> >>> would like the settings interfaces and perhaps ApplicationSettings to
> >>> be in a subpackage wicket.settings
> >>> they are all public API anyway and the main wicket package is getting
> >>> a bit monstrous.
> >>>
> >>> if it's just application settings that breaks app compat, i think it's
> >>> still 1.2, but haven't we broken app compat in a lot of other places
> >>> as well?
> >>> plus there are a lot of new features and problems solved... and wicket
> >>> 2.0 might get more attention...
> >>>
> >>> here is my first shot at factoring things into settings groups. i
> >>> think this came out pretty nice because there are some methods that
> >>> belong in two interefaces like throwExceptionOnMissingResource, which
> >>> you might look for via getResourceSettings() OR
> >>> getExceptionSettings(). both are logical places and both would work.
> >>>
> >>> Application
> >>> {
> >>> public String getName
> >>>
> >>> public void configure(final String configurationType);
> >>> public void configure(final String configurationType, final
> >>> IResourceFinder resourceFinder);
> >>> public void configure(final String configurationType, final String
> >>> resourceFolder);
> >>>
> >>> public ApplicationSettings getSettings() public IDebugSettings
> >>> getDebugSettings()
> >>> public IExceptionSettings getExceptionSettings()
> >>> public IMarkupSettings getMarkupSettings()
> >>> public IPageSettings getPageSettings()
> >>> public IRequestCycleSettings getRequestCycleSettings()
> >>> public IResourceSettings getResourceSettings()
> >>> public ISecuritySettings getSecuritySettings()
> >>> public ISessionSettings getSessionSettings()
> >>> public IRequiredPages getRequiredPages()
> >>> }
> >>>
> >>> IDebugSettings
> >>> {
> >>> componentUseCheck
> >>> }
> >>>
> >>> IExceptionSettings
> >>> {
> >>> unexpectedExceptionDisplay
> >>> throwExceptionOnMissingResource
> >>> }
> >>>
> >>> IMarkupSettings
> >>> {
> >>> additionalMarkupHandler
> >>> automaticLinking
> >>> compressWhitespace
> >>> defaultMarkupEncoding
> >>> defaultAfterDisabledLink
> >>> defaultBeforeDisabledLink
> >>> localizer
> >>> markupCache (maybe should be internal detail rather than setting?)
> >>> markupParserFactory
> >>> stripComments
> >>> stripWicketTags
> >>> stripXmlDeclarationFromOutput
> >>> }
> >>>
> >>> IPageSettings
> >>> {
> >>> converterFactory
> >>> maxPageVersions
> >>> versionPagesByDefault
> >>> }
> >>>
> >>> IRequestCycleSettings
> >>> {
> >>> addResponseFilter
> >>> bufferResponse
> >>> componentResolvers
> >>> defaultClassResolver (not just classResolver?)
> >>> renderStrategy
> >>> responseRequestEncoding
> >>> unexpectedExceptionDisplay
> >>> }
> >>>
> >>> IResourceSettings
> >>> {
> >>> addResourceFactory
> >>> addResourceFolder
> >>> addStringResourceLoader
> >>> defaultLocale
> >>> getResourceFactory
> >>> getValidatorResourceKey
> >>> propertiesFactory
> >>> resourceWatcher
> >>> resourceFinder
> >>> resourcePollFrequency
> >>> resourceStreamLocator
> >>> sharedResources
> >>> throwExceptionOnMissingResource
> >>> useDefaultOnMissingResource
> >>> }
> >>>
> >>> ISecuritySettings
> >>> {
> >>> authorizationStrategy
> >>> cookieValuePersisterSettings
> >>> crypt
> >>> encryptionKey
> >>> }
> >>>
> >>> ISessionSettings
> >>> {
> >>> pageFactory
> >>> pageMapEvictionStrategy
> >>> }
> >>>
> >>> IRequiredPages
> >>> {
> >>> homePage
> >>> internalErrorPage
> >>> pageExpiredErrorPage
> >>> }
> >>>
> >>> Juergen Donnerstag wrote:
> >>>
> >>>> +1 that is ok with me.
> >>>>
> >>>> It has to be mentioned though that this will break existing code (I
> >>>> know we are already not 100% backwards compatible). We sometime ago
> >>>> defined a release (version number) strategy which implied that
> >>>> changing the minor number does not (hardly) break existing code. Do
> >>>> the changes we made justify V2? Shall we call it 1.5 because of the
> >>>> significant changes or shall we still call it 1.2?
> >>>>
> >>>> Juergen
> >>>>
> >>>> On 1/1/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>
> >>>>> ive been discussing this with Jonathan off the list and here is what
> >>>>> we came
> >>>>> up with:
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
> >>>> -------------------------------------------------------
> >>>> 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&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
> >>
> >>
> >
> >
> > --
> > Living a wicket life...
> >
> > Martijn Dashorst - http://www.jroller.com/page/dashorst
> >
> > Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
> >
> >
> > -------------------------------------------------------
> > 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
>
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
N�HY隊X���'���u���[�������
ަ�k��!�� �W�~�鮆�zk��C� [EMAIL PROTECTED],���� a{� ��,�H��4�m���i�(��ܢo�v'
