btw, eelco's rethink/refactor of the request stuff was a really major piece of work.
we should all thank him for doing such a great job abstracting that.
jon
Jonathan Locke wrote:
as far as schedule goes, i think we should do this settings refactor and then just fix bugs. i think we've met all our major goals for 1.2 haven't we? we have pretty urls and even zero state pages with the (trivial) change i checked in today that keeps bookmarkable pages out of the session. eelco's request refactoring was the other major change and with a few minor refactors and name changes it looks quite good to me now... we could save the settings refactor for 1.3, but i don't think it will take igor very long to do. maybe a few hours. then 1.2 is the final thing we base the book on. very simple. just one release. that's my take.we're almost there, i'd say... 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 IResourceSettingsand localizer obviously belongs under IResourceSettings, not IMarkupSettingsoverall, 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 asetting 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 moreinterfaces. we can reuse the existing ApplicationSettings object as ourmonolithic 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 willneed to implement a factory interface as opposed to just overriding amethod. 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 agiant 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 ApplicationPagesentirely 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 simplevaluesin 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 makeanylogical sense of the division anyway. What's your vote? I think I'm +1, but I could be convinced to changemymind. Best, Jon-------------------------------------------------------This SF.net email is sponsored by: Splunk Inc. Do you grep throughlog filesfor problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOADSPLUNK! 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 logfilesfor problems? Stop! Download the new AJAX search engine that makessearching your log files as easy as surfing the web. DOWNLOADSPLUNK!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 logfilesfor problems? Stop! Download the new AJAX search engine that makessearching 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 logfilesfor problems? Stop! Download the new AJAX search engine that makessearching 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 makessearching 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 makessearching 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 filesfor 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 filesfor 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 filesfor 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=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
