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 PROTE
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
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 Lo
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 compo
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
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
>
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
strategi
yeah, we never intended for base class inheritance to be our design
here. it just ended up that way because we ran out of time and it
served as an example people could cut and paste from...
Erik van Oosten wrote:
>
> Hi Igor, Jonathan,
>
> Good idea, I have never liked the way I had to inhe
h. 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 Lo
yes. the generalization is what i'm more afraid of here...
igor.vaynberg wrote:
>
> 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 th
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 a
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 go
On 2/18/07, Igor Vaynberg <[EMAIL PROTECTED]> 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.
JMX isn't part of core for 1.3, which was the version I had in mind
when
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 i
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
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 PR
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
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 goi
18 matches
Mail list logo
