i guess another thing to consider is that in both of these cases there are
no sideeffects of installing these things. if you dont use the annots
everything is as it was before. so its not like you drop this file in and
all of a sudden things get weird.
-igor
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.
>
>
