unlike jmx this isnt part of core, so if you dont want to activate it dont
put it on your classpath. furthermore, like i said, there are no sideffects
in activating it.
the only downside i can think of is how to configure these things. usually
you would do it when installing them, but when they install themselves it
gets trickier. in case of wicket-spring there is no configuration....
-igor
On 2/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
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.
> >
> >
>
