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.
