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