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:
>> >>
>> >>
>> >>
>> >> aaaah. 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
>> >> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9047874
Sent from the Wicket - Dev mailing list archive at Nabble.com.
