if you're installing them explicitly, you have a nice type-safe constructor
with code completion help. and if you do need a config parameter later
you can add it and everyone on earth will know what happened.
igor.vaynberg wrote:
>
> 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.
>> > >
>> > >
>> >
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9045667
Sent from the Wicket - Dev mailing list archive at Nabble.com.
