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.
