Re: [Vote] wicket modules
if you're installing them explicitly, you have a nice type-safe constructor with code completion help. and if you do need a config parameter later you can add it and everyone on earth will know what happened. igor.vaynberg wrote: unlike jmx this isnt part of core, so if you dont want to activate it dont put it on your classpath. furthermore, like i said, there are no sideffects in activating it. the only downside i can think of is how to configure these things. usually you would do it when installing them, but when they install themselves it gets trickier. in case of wicket-spring there is no configuration -igor On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I like the idea. It's very much like the IInitializer idea anyway, and I agree it's funny we didn't actually think of this before. The only catch with auto-discovery/config/whateveryoucallit is - like we can see now with JMX - what do you do when people want it to be not activated. If we can have that as part of the pattern, I'm all for it. Eelco On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the componentinstantiationlistener, or what a componentinstantiationlistener is. there is also no need to make the user dig in though the docs and figure out they they need to have addComponentInstantionListener(new SpringComponentInjector(this)); to them its total garbage they just have to paste in. no one cares what it is, they only care @SpringBean fields are injected. so perhaps i should chage zero-configuration to zero-installation. same for security if i provide a module that provides a couple of annots like @Admin @User, etc and a security strategy for them - why make user go through all the gritty details of installing it. what if they have their own and want to mix it with the one in the module? they have to do all the wrapping themselves - it gets messy and the end result is exactly the same as when the module wouldve installed its own by itself. if we move to veto semantics for return values of strategies there is no difference how it is mixed in as long as it is. i dont know. if there is only one way to install something, why not have it done automatically? like i said, just thinking out loud -igor On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. I'm unsure about auto-installing modules using the classpath. With the classpath loading, you wind up with a lot of magic going on that you don't explicitly specify. I find that kind of zero config to be slippery, sometimes surprising and generally harder to manage than simply requiring a single line of code in your application constructor that makes it clear to everyone exactly what is supposed to happen (and when). It is very straightforward and self-documenting to explicitly state the dependency for each module you want to use in your app constructor. It's extremely hard to mistake the intention of something like add(new WhateverModule()). You don't have to know anything about how Wicket modules might work to figure it out. I also think that the current approach of having /a/ security strategy is quite elegant and straightforward. The mechanism is extensible by explicit chaining and I think probably better than a fancy one that has locators, searching or cascading because you end up with magic again. Saying add(new WebApplicationAuthenticator()) (instead of extending AuthenticatedWebApplication) lets you to add web application authentication functionality without having to educate anyone about how it happens. I think what we should be shooting for is an easy way to use modules in Wicket that add behavior explicitly in your application constructor. I think this ought to be some kind of simple and explicit pattern of composition. I like the start of what you're thinking here, but let's be careful not to invent for invention's sake. Wicket would best remain a highly predictable and simple framework. igor.vaynberg wrote: just thinking out loud... for a long time we have had problems with addons that have their own application subclass because if you wanted to use more then one addon you had to bastardize the code of one and add it to the application subclass of the other. recently i refactored wicket-spring to not have its own application
Re: [Vote] wicket modules
yes. the generalization is what i'm more afraid of here...
igor.vaynberg wrote:
i guess another thing to consider is that in both of these cases there are
no sideeffects of installing these things. if you dont use the annots
everything is as it was before. so its not like you drop this file in and
all of a sudden things get weird.
-igor
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i disagree. having things explicit is very nice when there is a need for
you to know, but what if there isnt?
take wicket-spring module. its only service is to make fields annotated
with @SpringBean injectable. why should the user care that this is done
with
the componentinstantiationlistener, or what a
componentinstantiationlistener
is.
there is also no need to make the user dig in though the docs and figure
out they they need to have
addComponentInstantionListener(new SpringComponentInjector(this));
to them its total garbage they just have to paste in. no one cares what
it
is, they only care @SpringBean fields are injected.
so perhaps i should chage zero-configuration to zero-installation.
same for security
if i provide a module that provides a couple of annots like @Admin @User,
etc and a security strategy for them - why make user go through all the
gritty details of installing it. what if they have their own and want to
mix
it with the one in the module? they have to do all the wrapping
themselves -
it gets messy and the end result is exactly the same as when the module
wouldve installed its own by itself. if we move to veto semantics for
return
values of strategies there is no difference how it is mixed in as long as
it
is.
i dont know. if there is only one way to install something, why not have
it done automatically?
like i said, just thinking out loud
-igor
On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote:
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with
what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you
don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply
requiring a
single line of code in your application constructor that makes it clear
to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency
for
each module you want to use in your app constructor. It's extremely
hard to
mistake the intention of something like add(new
WhateverModule()). You
don't have to know anything about how Wicket modules might work to
figure it
out.
I also think that the current approach of having /a/ security strategy
is
quite elegant and straightforward. The mechanism is extensible by
explicit
chaining and I think probably better than a fancy one that has
locators,
searching or cascading because you end up with magic again. Saying
add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application
authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not
to
invent for invention's sake. Wicket would best remain a highly
predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon
you
had to bastardize the code of one and add it to the application
subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install
that
would take place of the module-specific application subclass. and
then
i
thought about it some more and realized we already have something
like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just
refactored
wicket-spring to work like this, it uses an initializer to register
the
springcomponnetinjector so now for user there is zero-configuration.
drop
the jar onto the classpath and its ready to go. why didnt i do this a
long
time ago? :|
now for security stuff we can also do some really cool
Re: [Vote] wicket modules
h. i'm a bit slow this morning. the reason you want to change authorization is because auto module initialization doesn't permit easy parameters to the module such as: add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...)); (or whatever name best fits this module) Jonathan Locke wrote: i agree that not having to know this: addComponentInstantionListener(new SpringComponentInjector(this)); is where any kind of module system could improve on the current way of doing things. but there is still a need to know how this is happening for new users of a project. something magic is going on when you start a wicket application with auto-loaded modules and eventually there will be issues about load order because there CAN be. i think the best thing would be to figure out some easy way for the user to discover what modules they can install by putting in a simple line of code. one easy way to do that, for example, would be to have a prefixing convention so that they pop up in your IDE. addModule(new WicketModule could give you a list of modules via code completion such as WicketModuleSpringBeanInjector. the advantage is that a casual observer later is going to know how this module is getting loaded and when. you also have some idea what modules are available. if they are getting auto-loaded you will only know this if you know what's on the classpath somehow. the code completion functions as a kind of self-documentation. there are probably other ways to do this. i'd just like to find something simpler and less automatic. i feel like there's a second issue being tacked on here. is there really a need to change authorization to accomodate modules? it seems to work really well for me. it's straightforward and there's one place to look to find out how an application is being authorized. igor.vaynberg wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the componentinstantiationlistener, or what a componentinstantiationlistener is. there is also no need to make the user dig in though the docs and figure out they they need to have addComponentInstantionListener(new SpringComponentInjector(this)); to them its total garbage they just have to paste in. no one cares what it is, they only care @SpringBean fields are injected. so perhaps i should chage zero-configuration to zero-installation. same for security if i provide a module that provides a couple of annots like @Admin @User, etc and a security strategy for them - why make user go through all the gritty details of installing it. what if they have their own and want to mix it with the one in the module? they have to do all the wrapping themselves - it gets messy and the end result is exactly the same as when the module wouldve installed its own by itself. if we move to veto semantics for return values of strategies there is no difference how it is mixed in as long as it is. i dont know. if there is only one way to install something, why not have it done automatically? like i said, just thinking out loud -igor On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. I'm unsure about auto-installing modules using the classpath. With the classpath loading, you wind up with a lot of magic going on that you don't explicitly specify. I find that kind of zero config to be slippery, sometimes surprising and generally harder to manage than simply requiring a single line of code in your application constructor that makes it clear to everyone exactly what is supposed to happen (and when). It is very straightforward and self-documenting to explicitly state the dependency for each module you want to use in your app constructor. It's extremely hard to mistake the intention of something like add(new WhateverModule()). You don't have to know anything about how Wicket modules might work to figure it out. I also think that the current approach of having /a/ security strategy is quite elegant and straightforward. The mechanism is extensible by explicit chaining and I think probably better than a fancy one that has locators, searching or cascading because you end up with magic again. Saying add(new WebApplicationAuthenticator()) (instead of extending AuthenticatedWebApplication) lets you to add web application authentication functionality without having to educate anyone about how it happens. I think what we should be shooting for is an easy way to use modules in Wicket that add behavior explicitly in your application
Re: [Vote] wicket modules
you can have multiple strategies easily working together. just keep looping through them until you get a false out of one (a veto) and then stop. if no false then it passes - true. just what a compound strat would do. but setonce and exception wont work. then module can never set one, so we lose all that goodness. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: you could easily have a set-once policy and throw an exception. i don't understand what you mean by add with veto. igor.vaynberg wrote: the thing i dont like about is that if a module installs a strategy the user can then later overwrite that strategy in security settings by simply calling set with his own. its the semantics of set/get vs add that suck in this case, add is more preferrable with veto return values from the strategies. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: h. i'm a bit slow this morning. the reason you want to change authorization is because auto module initialization doesn't permit easy parameters to the module such as: add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...)); (or whatever name best fits this module) Jonathan Locke wrote: i agree that not having to know this: addComponentInstantionListener(new SpringComponentInjector(this)); is where any kind of module system could improve on the current way of doing things. but there is still a need to know how this is happening for new users of a project. something magic is going on when you start a wicket application with auto-loaded modules and eventually there will be issues about load order because there CAN be. i think the best thing would be to figure out some easy way for the user to discover what modules they can install by putting in a simple line of code. one easy way to do that, for example, would be to have a prefixing convention so that they pop up in your IDE. addModule(new WicketModule could give you a list of modules via code completion such as WicketModuleSpringBeanInjector. the advantage is that a casual observer later is going to know how this module is getting loaded and when. you also have some idea what modules are available. if they are getting auto-loaded you will only know this if you know what's on the classpath somehow. the code completion functions as a kind of self-documentation. there are probably other ways to do this. i'd just like to find something simpler and less automatic. i feel like there's a second issue being tacked on here. is there really a need to change authorization to accomodate modules? it seems to work really well for me. it's straightforward and there's one place to look to find out how an application is being authorized. igor.vaynberg wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the componentinstantiationlistener, or what a componentinstantiationlistener is. there is also no need to make the user dig in though the docs and figure out they they need to have addComponentInstantionListener(new SpringComponentInjector(this)); to them its total garbage they just have to paste in. no one cares what it is, they only care @SpringBean fields are injected. so perhaps i should chage zero-configuration to zero-installation. same for security if i provide a module that provides a couple of annots like @Admin @User, etc and a security strategy for them - why make user go through all the gritty details of installing it. what if they have their own and want to mix it with the one in the module? they have to do all the wrapping themselves - it gets messy and the end result is exactly the same as when the module wouldve installed its own by itself. if we move to veto semantics for return values of strategies there is no difference how it is mixed in as long as it is. i dont know. if there is only one way to install something, why not have it done automatically? like i said, just thinking out loud -igor On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. I'm unsure about auto-installing modules using the classpath. With the classpath loading, you wind up with a lot of magic going on that you don't explicitly specify. I find that kind of zero config to be slippery, sometimes surprising and generally harder to manage than simply requiring a single line of code in your application constructor that makes it clear to
Re: [Vote] wicket modules
we do disagree. i don't believe in the ability of module designers to create modules that seamlessly interoperate. we had this problem almost 20 years ago with windows hooks and it was a complete disaster. i've seen it repeated in other places in oo systems and it's a mess there too. i think you want to provide a mechanism where someone (possibly the authors of one or more modules, but ultimately the user if need be) can very explicitly determine how those modules interoperate. if you make the glue explicit you make interoperation a little more verbose, but at that expense it is extremely simple and deterministic. when you start to have really difficult problems or even unresolvable conflicts between what modules need in terms of resources, you will eventually discover the limits of automatic mixing. the results have not been pretty in the past. igor.vaynberg wrote: see this is where we would disagree. if a strategy adds some annots for you to use the compoudness is seamless. as long as the strategy in the module is designed as an mixin it should work just fine no matter what user has got going. thats why its an interface :) -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: set once and exception does work because only the module sets it. trying to make multiple strategies co-operate seamlessly is a losing battle that i have seen many times before. i think when you want to make that happen it's better to explicitly code a compound strategy (or use the simple compound strategy provided already). igor.vaynberg wrote: you can have multiple strategies easily working together. just keep looping through them until you get a false out of one (a veto) and then stop. if no false then it passes - true. just what a compound strat would do. but setonce and exception wont work. then module can never set one, so we lose all that goodness. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: you could easily have a set-once policy and throw an exception. i don't understand what you mean by add with veto. igor.vaynberg wrote: the thing i dont like about is that if a module installs a strategy the user can then later overwrite that strategy in security settings by simply calling set with his own. its the semantics of set/get vs add that suck in this case, add is more preferrable with veto return values from the strategies. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: h. i'm a bit slow this morning. the reason you want to change authorization is because auto module initialization doesn't permit easy parameters to the module such as: add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...)); (or whatever name best fits this module) Jonathan Locke wrote: i agree that not having to know this: addComponentInstantionListener(new SpringComponentInjector(this)); is where any kind of module system could improve on the current way of doing things. but there is still a need to know how this is happening for new users of a project. something magic is going on when you start a wicket application with auto-loaded modules and eventually there will be issues about load order because there CAN be. i think the best thing would be to figure out some easy way for the user to discover what modules they can install by putting in a simple line of code. one easy way to do that, for example, would be to have a prefixing convention so that they pop up in your IDE. addModule(new WicketModule could give you a list of modules via code completion such as WicketModuleSpringBeanInjector. the advantage is that a casual observer later is going to know how this module is getting loaded and when. you also have some idea what modules are available. if they are getting auto-loaded you will only know this if you know what's on the classpath somehow. the code completion functions as a kind of self-documentation. there are probably other ways to do this. i'd just like to find something simpler and less automatic. i feel like there's a second issue being tacked on here. is there really a need to change authorization to accomodate modules? it seems to work really well for me. it's straightforward and there's one place to look to find out how an application is being authorized. igor.vaynberg wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the
Re: [Vote] wicket modules
yes, on large scale maybe. i am talking about small self-contained modules. and this isnt really InstallHook :) not all approaches like this are bad. eclipse/osgi is one example where there are a ton of tiny modules that work together really well. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: we do disagree. i don't believe in the ability of module designers to create modules that seamlessly interoperate. we had this problem almost 20 years ago with windows hooks and it was a complete disaster. i've seen it repeated in other places in oo systems and it's a mess there too. i think you want to provide a mechanism where someone (possibly the authors of one or more modules, but ultimately the user if need be) can very explicitly determine how those modules interoperate. if you make the glue explicit you make interoperation a little more verbose, but at that expense it is extremely simple and deterministic. when you start to have really difficult problems or even unresolvable conflicts between what modules need in terms of resources, you will eventually discover the limits of automatic mixing. the results have not been pretty in the past. igor.vaynberg wrote: see this is where we would disagree. if a strategy adds some annots for you to use the compoudness is seamless. as long as the strategy in the module is designed as an mixin it should work just fine no matter what user has got going. thats why its an interface :) -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: set once and exception does work because only the module sets it. trying to make multiple strategies co-operate seamlessly is a losing battle that i have seen many times before. i think when you want to make that happen it's better to explicitly code a compound strategy (or use the simple compound strategy provided already). igor.vaynberg wrote: you can have multiple strategies easily working together. just keep looping through them until you get a false out of one (a veto) and then stop. if no false then it passes - true. just what a compound strat would do. but setonce and exception wont work. then module can never set one, so we lose all that goodness. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: you could easily have a set-once policy and throw an exception. i don't understand what you mean by add with veto. igor.vaynberg wrote: the thing i dont like about is that if a module installs a strategy the user can then later overwrite that strategy in security settings by simply calling set with his own. its the semantics of set/get vs add that suck in this case, add is more preferrable with veto return values from the strategies. -igor On 2/19/07, Jonathan Locke [EMAIL PROTECTED] wrote: h. i'm a bit slow this morning. the reason you want to change authorization is because auto module initialization doesn't permit easy parameters to the module such as: add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...)); (or whatever name best fits this module) Jonathan Locke wrote: i agree that not having to know this: addComponentInstantionListener(new SpringComponentInjector(this)); is where any kind of module system could improve on the current way of doing things. but there is still a need to know how this is happening for new users of a project. something magic is going on when you start a wicket application with auto-loaded modules and eventually there will be issues about load order because there CAN be. i think the best thing would be to figure out some easy way for the user to discover what modules they can install by putting in a simple line of code. one easy way to do that, for example, would be to have a prefixing convention so that they pop up in your IDE. addModule(new WicketModule could give you a list of modules via code completion such as WicketModuleSpringBeanInjector. the advantage is that a casual observer later is going to know how this module is getting loaded and when. you also have some idea what modules are available. if they are getting auto-loaded you will only know this if you know what's on the classpath somehow. the code completion functions as a kind of self-documentation. there are probably other ways to do this. i'd just like to find something simpler and less automatic. i feel like there's a second issue being tacked on here. is there really a need to change authorization to accomodate modules? it seems to work really well for me. it's straightforward and there's one place to look to find out how an application is being authorized. igor.vaynberg wrote:
Re: [Vote] wicket modules
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply requiring a
single line of code in your application constructor that makes it clear to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency for
each module you want to use in your app constructor. It's extremely hard to
mistake the intention of something like add(new WhateverModule()). You
don't have to know anything about how Wicket modules might work to figure it
out.
I also think that the current approach of having /a/ security strategy is
quite elegant and straightforward. The mechanism is extensible by explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not to
invent for invention's sake. Wicket would best remain a highly predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon you
had to bastardize the code of one and add it to the application subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install that
would take place of the module-specific application subclass. and then i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just refactored
wicket-spring to work like this, it uses an initializer to register the
springcomponnetinjector so now for user there is zero-configuration. drop
the jar onto the classpath and its ready to go. why didnt i do this a long
time ago? :|
now for security stuff we can also do some really cool things. it gets a
bit
controversial here but bare with me. what if we let the security strategy
cascade from session-application-modules and instead of returning true
or
false it returns pass or veto? the controversial bit is removing security
strategy from a setting and letting session, application, wicketmodule be
able to implement it directly - or implement a locator interface. this way
installing wicket-auth is pretty simple, drop the jar in and create your
own
roles. the module takes care of installing the right security strategy,
etc.
could be cool, the module interface can be extended to handle other
usefull
callbacks, etc.
-igor
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9037838
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] wicket modules
i disagree. having things explicit is very nice when there is a need for you
to know, but what if there isnt?
take wicket-spring module. its only service is to make fields annotated with
@SpringBean injectable. why should the user care that this is done with the
componentinstantiationlistener, or what a componentinstantiationlistener is.
there is also no need to make the user dig in though the docs and figure out
they they need to have
addComponentInstantionListener(new SpringComponentInjector(this));
to them its total garbage they just have to paste in. no one cares what it
is, they only care @SpringBean fields are injected.
so perhaps i should chage zero-configuration to zero-installation.
same for security
if i provide a module that provides a couple of annots like @Admin @User,
etc and a security strategy for them - why make user go through all the
gritty details of installing it. what if they have their own and want to mix
it with the one in the module? they have to do all the wrapping themselves -
it gets messy and the end result is exactly the same as when the module
wouldve installed its own by itself. if we move to veto semantics for return
values of strategies there is no difference how it is mixed in as long as it
is.
i dont know. if there is only one way to install something, why not have it
done automatically?
like i said, just thinking out loud
-igor
On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote:
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with
what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply requiring
a
single line of code in your application constructor that makes it clear to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency
for
each module you want to use in your app constructor. It's extremely hard
to
mistake the intention of something like add(new WhateverModule()). You
don't have to know anything about how Wicket modules might work to figure
it
out.
I also think that the current approach of having /a/ security strategy is
quite elegant and straightforward. The mechanism is extensible by
explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying
add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application
authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not to
invent for invention's sake. Wicket would best remain a highly
predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon
you
had to bastardize the code of one and add it to the application subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install that
would take place of the module-specific application subclass. and then i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just
refactored
wicket-spring to work like this, it uses an initializer to register the
springcomponnetinjector so now for user there is zero-configuration.
drop
the jar onto the classpath and its ready to go. why didnt i do this a
long
time ago? :|
now for security stuff we can also do some really cool things. it gets a
bit
controversial here but bare with me. what if we let the security
strategy
cascade from session-application-modules and instead of returning true
or
false it returns pass or veto? the controversial bit is removing
security
strategy from a setting and letting session, application, wicketmodule
be
able to implement it directly - or implement a locator interface. this
way
installing wicket-auth is pretty simple, drop the jar in and create your
own
roles. the module takes care of installing the right security strategy,
etc.
could be cool, the module interface can be
Re: [Vote] wicket modules
i guess another thing to consider is that in both of these cases there are
no sideeffects of installing these things. if you dont use the annots
everything is as it was before. so its not like you drop this file in and
all of a sudden things get weird.
-igor
On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i disagree. having things explicit is very nice when there is a need for
you to know, but what if there isnt?
take wicket-spring module. its only service is to make fields annotated
with @SpringBean injectable. why should the user care that this is done with
the componentinstantiationlistener, or what a componentinstantiationlistener
is.
there is also no need to make the user dig in though the docs and figure
out they they need to have
addComponentInstantionListener(new SpringComponentInjector(this));
to them its total garbage they just have to paste in. no one cares what it
is, they only care @SpringBean fields are injected.
so perhaps i should chage zero-configuration to zero-installation.
same for security
if i provide a module that provides a couple of annots like @Admin @User,
etc and a security strategy for them - why make user go through all the
gritty details of installing it. what if they have their own and want to mix
it with the one in the module? they have to do all the wrapping themselves -
it gets messy and the end result is exactly the same as when the module
wouldve installed its own by itself. if we move to veto semantics for return
values of strategies there is no difference how it is mixed in as long as it
is.
i dont know. if there is only one way to install something, why not have
it done automatically?
like i said, just thinking out loud
-igor
On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote:
I like the idea of snap-in modules of some sort, but I don't completely
understand what you're talking about here and I'm not sure I agree with
what
all of what I do get.
I'm unsure about auto-installing modules using the classpath. With the
classpath loading, you wind up with a lot of magic going on that you
don't
explicitly specify. I find that kind of zero config to be slippery,
sometimes surprising and generally harder to manage than simply
requiring a
single line of code in your application constructor that makes it clear
to
everyone exactly what is supposed to happen (and when). It is very
straightforward and self-documenting to explicitly state the dependency
for
each module you want to use in your app constructor. It's extremely
hard to
mistake the intention of something like add(new
WhateverModule()). You
don't have to know anything about how Wicket modules might work to
figure it
out.
I also think that the current approach of having /a/ security strategy
is
quite elegant and straightforward. The mechanism is extensible by
explicit
chaining and I think probably better than a fancy one that has locators,
searching or cascading because you end up with magic again. Saying
add(new
WebApplicationAuthenticator()) (instead of extending
AuthenticatedWebApplication) lets you to add web application
authentication
functionality without having to educate anyone about how it happens.
I think what we should be shooting for is an easy way to use modules in
Wicket that add behavior explicitly in your application constructor. I
think this ought to be some kind of simple and explicit pattern of
composition.
I like the start of what you're thinking here, but let's be careful not
to
invent for invention's sake. Wicket would best remain a highly
predictable
and simple framework.
igor.vaynberg wrote:
just thinking out loud...
for a long time we have had problems with addons that have their own
application subclass because if you wanted to use more then one addon
you
had to bastardize the code of one and add it to the application
subclass
of
the other. recently i refactored wicket-spring to not have its own
application subclass, but the user still had to install the component
injector - and needs to know how to do that.
i thought it would be great to have modules that users can install
that
would take place of the module-specific application subclass. and then
i
thought about it some more and realized we already have something like
that.
interface wicketmodule extends iinitializer, idestroyer {}
and there you have it, a beginnings of a wicket module. i just
refactored
wicket-spring to work like this, it uses an initializer to register
the
springcomponnetinjector so now for user there is zero-configuration.
drop
the jar onto the classpath and its ready to go. why didnt i do this a
long
time ago? :|
now for security stuff we can also do some really cool things. it gets
a
bit
controversial here but bare with me. what if we let the security
strategy
cascade from session-application-modules and instead of returning
true
or
false it returns pass or veto? the
Re: [Vote] wicket modules
unlike jmx this isnt part of core, so if you dont want to activate it dont put it on your classpath. furthermore, like i said, there are no sideffects in activating it. the only downside i can think of is how to configure these things. usually you would do it when installing them, but when they install themselves it gets trickier. in case of wicket-spring there is no configuration -igor On 2/18/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I like the idea. It's very much like the IInitializer idea anyway, and I agree it's funny we didn't actually think of this before. The only catch with auto-discovery/config/whateveryoucallit is - like we can see now with JMX - what do you do when people want it to be not activated. If we can have that as part of the pattern, I'm all for it. Eelco On 2/18/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i disagree. having things explicit is very nice when there is a need for you to know, but what if there isnt? take wicket-spring module. its only service is to make fields annotated with @SpringBean injectable. why should the user care that this is done with the componentinstantiationlistener, or what a componentinstantiationlistener is. there is also no need to make the user dig in though the docs and figure out they they need to have addComponentInstantionListener(new SpringComponentInjector(this)); to them its total garbage they just have to paste in. no one cares what it is, they only care @SpringBean fields are injected. so perhaps i should chage zero-configuration to zero-installation. same for security if i provide a module that provides a couple of annots like @Admin @User, etc and a security strategy for them - why make user go through all the gritty details of installing it. what if they have their own and want to mix it with the one in the module? they have to do all the wrapping themselves - it gets messy and the end result is exactly the same as when the module wouldve installed its own by itself. if we move to veto semantics for return values of strategies there is no difference how it is mixed in as long as it is. i dont know. if there is only one way to install something, why not have it done automatically? like i said, just thinking out loud -igor On 2/18/07, Jonathan Locke [EMAIL PROTECTED] wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. I'm unsure about auto-installing modules using the classpath. With the classpath loading, you wind up with a lot of magic going on that you don't explicitly specify. I find that kind of zero config to be slippery, sometimes surprising and generally harder to manage than simply requiring a single line of code in your application constructor that makes it clear to everyone exactly what is supposed to happen (and when). It is very straightforward and self-documenting to explicitly state the dependency for each module you want to use in your app constructor. It's extremely hard to mistake the intention of something like add(new WhateverModule()). You don't have to know anything about how Wicket modules might work to figure it out. I also think that the current approach of having /a/ security strategy is quite elegant and straightforward. The mechanism is extensible by explicit chaining and I think probably better than a fancy one that has locators, searching or cascading because you end up with magic again. Saying add(new WebApplicationAuthenticator()) (instead of extending AuthenticatedWebApplication) lets you to add web application authentication functionality without having to educate anyone about how it happens. I think what we should be shooting for is an easy way to use modules in Wicket that add behavior explicitly in your application constructor. I think this ought to be some kind of simple and explicit pattern of composition. I like the start of what you're thinking here, but let's be careful not to invent for invention's sake. Wicket would best remain a highly predictable and simple framework. igor.vaynberg wrote: just thinking out loud... for a long time we have had problems with addons that have their own application subclass because if you wanted to use more then one addon you had to bastardize the code of one and add it to the application subclass of the other. recently i refactored wicket-spring to not have its own application subclass, but the user still had to install the component injector - and needs to know how to do that. i thought it would be great to have modules that users can install that would take place of the module-specific application subclass. and then i thought about it some more and realized we already have something like that. interface wicketmodule extends
