Forgive me if I am wrong, but I thought that unknown annotations must be
ignored by the Java compiler. If not, I stand corrected.
About logging: there is usually too much logging already. Logging is
mostly useful for negative messages. Extracting more information from a
log takes the hours I
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
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
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
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
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
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
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
). 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
-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
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
Hi Igor, Jonathan,
Good idea, I have never liked the way I had to inherit from the
application base classes.
From a users point of view, I agree with Jonathan on the config thing,
I'd rather have one line of code somewhere (on a predictable place, e.g.
application#init). This also makes it
all these cons are invalid
you would also get class not found on the annotations like @SpringBean
and a log message tells you what modules have been initialized
:)
-igor
On 2/18/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi Igor, Jonathan,
Good idea, I have never liked the way I had to
-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
14 matches
Mail list logo
