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#a9045612
Sent from the Wicket - Dev mailing list archive at Nabble.com.
