yes, on large scale maybe. i am talking about small self-contained modules.
and this isnt really InstallHook :)
not all approaches like this are bad. eclipse/osgi is one example where
there are a ton of tiny modules that work together really well.
-igor
On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
we do disagree. i don't believe in the ability of module designers to
create
modules that seamlessly interoperate. we had this problem almost 20 years
ago with windows hooks and it was a complete disaster. i've seen it
repeated
in other places in oo systems and it's a mess there too. i think you want
to
provide a mechanism where someone (possibly the authors of one or more
modules, but ultimately the user if need be) can very explicitly determine
how those modules interoperate. if you make the glue explicit you make
interoperation a little more verbose, but at that expense it is extremely
simple and deterministic. when you start to have really difficult
problems
or
even unresolvable conflicts between what modules need in terms of
resources,
you will eventually discover the limits of automatic mixing. the results
have
not been pretty in the past.
igor.vaynberg wrote:
>
> see this is where we would disagree. if a strategy adds some annots for
> you
> to use the compoudness is seamless. as long as the strategy in the
module
> is
> designed as an "mixin" it should work just fine no matter what user has
> got
> going. thats why its an interface :)
>
> -igor
>
>
> On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> set once and exception does work because only the module sets it.
>>
>> trying to make multiple strategies co-operate seamlessly is a losing
>> battle that i have seen many times before. i think when you want to
>> make that happen it's better to explicitly code a compound strategy
>> (or use the simple compound strategy provided already).
>>
>>
>> igor.vaynberg wrote:
>> >
>> > you can have multiple strategies easily working together. just keep
>> > looping
>> > through them until you get a false out of one (a veto) and then stop.
>> if
>> > no
>> > false then it passes - true. just what a compound strat would do.
>> >
>> > but setonce and exception wont work. then module can never set one,
so
>> we
>> > lose all that goodness.
>> >
>> > -igor
>> >
>> > On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >>
>> >> you could easily have a set-once policy and throw an exception.
>> >>
>> >> i don't understand what you mean by add with veto.
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > the thing i dont like about is that if a module installs a
strategy
>> the
>> >> > user
>> >> > can then later overwrite that strategy in security settings by
>> simply
>> >> > calling set with his own. its the semantics of set/get vs add that
>> suck
>> >> in
>> >> > this case, add is more preferrable with veto return values from
the
>> >> > strategies.
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On 2/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> aaaah. i'm a bit slow this morning. the reason you want to
change
>> >> >> authorization
>> >> >> is because auto module initialization doesn't permit easy
>> parameters
>> >> to
>> >> >> the
>> >> >> module
>> >> >> such as:
>> >> >>
>> >> >> add(new WicketModuleAnnotatedRoleSecurity(Application.this,
...));
>> >> >>
>> >> >> (or whatever name best fits this module)
>> >> >>
>> >> >>
>> >> >> Jonathan Locke wrote:
>> >> >> >
>> >> >> >
>> >> >> > i agree that not having to know this:
>> >> >> >
>> >> >> > addComponentInstantionListener(new
>> SpringComponentInjector(this));
>> >> >> >
>> >> >> > is where any kind of module system could improve on the current
>> way
>> >> of
>> >> >> > doing things.
>> >> >> > but there is still a need to know how this is happening for new
>> >> users
>> >> >> of
>> >> >> a
>> >> >> > project.
>> >> >> > something magic is going on when you start a wicket application
>> with
>> >> >> > auto-loaded
>> >> >> > modules and eventually there will be issues about load order
>> because
>> >> >> there
>> >> >> > CAN be.
>> >> >> >
>> >> >> > i think the best thing would be to figure out some easy way for
>> the
>> >> >> user
>> >> >> > to discover
>> >> >> > what modules they can install by putting in a simple line of
>> >> code. one
>> >> >> > easy way to
>> >> >> > do that, for example, would be to have a prefixing convention
so
>> >> that
>> >> >> they
>> >> >> > pop up
>> >> >> > in your IDE. "addModule(new WicketModule" could give you a
list
>> of
>> >> >> > modules via
>> >> >> > code completion such as "WicketModuleSpringBeanInjector". the
>> >> >> advantage
>> >> >> > is that
>> >> >> > a casual observer later is going to know how this module is
>> getting
>> >> >> loaded
>> >> >> > and when.
>> >> >> > you also have some idea what modules are available. if they
are
>> >> >> getting
>> >> >> > auto-loaded
>> >> >> > you will only know this if you know what's on the classpath
>> >> >> somehow. the
>> >> >> > code
>> >> >> > completion functions as a kind of self-documentation. there
are
>> >> >> probably
>> >> >> > other ways
>> >> >> > to do this. i'd just like to find something simpler and less
>> >> >> automatic.
>> >> >> >
>> >> >> > i feel like there's a second issue being tacked on here. is
>> there
>> >> >> really
>> >> >> > a need to
>> >> >> > change authorization to accomodate modules? it seems to work
>> really
>> >> >> well
>> >> >> > for me.
>> >> >> > it's straightforward and there's one place to look to find out
>> how
>> >> an
>> >> >> > application is
>> >> >> > being authorized.
>> >> >> >
>> >> >> >
>> >> >> > igor.vaynberg 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#a9045749
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/wicket-modules-tf3250868.html#a9047743
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/wicket-modules-tf3250868.html#a9047874
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-modules-tf3250868.html#a9048560
Sent from the Wicket - Dev mailing list archive at Nabble.com.
