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
