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.
