-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=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to