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.
