Re: [Vote] wicket modules
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 >
Re: [Vote] wicket modules
to-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 >> &g
Re: [Vote] wicket modules
> 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 >> >> de
Re: [Vote] wicket modules
ized. >> >> > >> >> > >> >> > 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())". >> >&g
Re: [Vote] wicket modules
gt;>
>> >> 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 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.
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/wicket-modules-tf3250868.html#a9045749
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9047743
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] wicket modules
y 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 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.
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/wicket-modules-tf3250868.html#a9045749
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9047743
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] wicket modules
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 confi
Re: [Vote] wicket modules
yeah, we never intended for base class inheritance to be our design here. it just ended up that way because we ran out of time and it served as an example people could cut and paste from... Erik van Oosten wrote: > > Hi Igor, Jonathan, > > Good idea, I have never liked the way I had to inherit from the > application base classes. > > From a users point of view, I agree with Jonathan on the config thing, > I'd rather have one line of code somewhere (on a predictable place, e.g. > application#init). This also makes it immediately clear when it does not > work: you get a classnotfoundexception. When it is implicit you can > search for hours before you realize that a jar is missing. Especially > when you are talking about annotations. > > Regards, > Erik. > > > Jonathan Locke 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. >> > > -- > Erik van Oosten > http://www.day-to-day-stuff.blogspot.com/ > > > -- View this message in context: http://www.nabble.com/wicket-modules-tf3250868.html#a9045750 Sent from the Wicket - Dev mailing list archive at Nabble.com.
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
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. >> > >> > >&
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. >> > > >>
Re: [Vote] wicket modules
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 >> AuthenticatedWebA
Re: [Vote] wicket modules
On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> 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. JMX isn't part of core for 1.3, which was the version I had in mind when I made the comment. But even then, you would still have to provide a way to turn it off 'by hand'. You might not want to use the functionality of a module, but still need to include it because otherwise your app won't compile. For instance. The point is that you need an ultimate override. Eelco
Re: wicket modules
i get an error when i put @Foo on a field in eclipse (give its not the standard) so i dont know if javac is supposed to ignore them or not. can you try? as far as logging, i think a single INFO: Wicket-Spring Module Initialized is very easy to check for. -igor On 2/19/07, Erik van Oosten <[EMAIL PROTECTED]> wrote: Forgive me if I am wrong, but I thought that unknown annotations must be ignored by the Java compiler. If not, I stand corrected. About logging: there is usually too much logging already. Logging is mostly useful for negative messages. Extracting more information from a log takes the hours I was talking about. :( Debugging is more effective most of the time. Regards, Erik. Igor Vaynberg wrote: > all these cons are invalid > you would also get class not found on the annotations like @SpringBean > and a log message tells you what modules have been initialized > > :) > > -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: wicket modules
Forgive me if I am wrong, but I thought that unknown annotations must be ignored by the Java compiler. If not, I stand corrected. About logging: there is usually too much logging already. Logging is mostly useful for negative messages. Extracting more information from a log takes the hours I was talking about. :( Debugging is more effective most of the time. Regards, Erik. Igor Vaynberg wrote: all these cons are invalid you would also get class not found on the annotations like @SpringBean and a log message tells you what modules have been initialized :) -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
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... &
Re: wicket modules
all these cons are invalid you would also get class not found on the annotations like @SpringBean and a log message tells you what modules have been initialized :) -igor On 2/18/07, Erik van Oosten <[EMAIL PROTECTED]> wrote: Hi Igor, Jonathan, Good idea, I have never liked the way I had to inherit from the application base classes. From a users point of view, I agree with Jonathan on the config thing, I'd rather have one line of code somewhere (on a predictable place, e.g. application#init). This also makes it immediately clear when it does not work: you get a classnotfoundexception. When it is implicit you can search for hours before you realize that a jar is missing. Especially when you are talking about annotations. Regards, Erik. Jonathan Locke 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. > -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [Vote] wicket modules
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 iinitializer, idestroyer {}
> >
> > and there you have it,
Re: wicket modules
Hi Igor, Jonathan, Good idea, I have never liked the way I had to inherit from the application base classes. From a users point of view, I agree with Jonathan on the config thing, I'd rather have one line of code somewhere (on a predictable place, e.g. application#init). This also makes it immediately clear when it does not work: you get a classnotfoundexception. When it is implicit you can search for hours before you realize that a jar is missing. Especially when you are talking about annotations. Regards, Erik. Jonathan Locke 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. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
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
> >
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 direct
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.
wicket modules
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
