I like the idea. It's very much like the IInitializer idea anyway, and
I agree it's funny we didn't actually think of this before. The only
catch with auto-discovery/config/whateveryoucallit is - like we can
see now with JMX - what do you do when people want it to be not
activated. If we can have that as part of the pattern, I'm all for it.
Eelco
On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> 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.
>
>
