One of the reasons why our way of just using Java object is better is
that it leaves open all the options you want. You prefer annotations
there? That's fine/ easy to accomplish with Wicket. The other way
around, going from some declarative model back to another
representation (either plain programming or a different declarative
model) can just not be done. In that sense Wicket gives you more
freedom.
Now, there is more than just freedom, having good defaults is just as
important. Whether you like anonymous classes is a personal thing it
seems. People can rave about closures in other languages, but loath
anonymous classes in Java for some reason. The good thing is that if
you don't like them, you don't have to use them. Just make a normal
subclass. Which actually makes sense in an OO fashion here too, as the
ajax callback would probably do something very specific. And if you
run into that specific situation more than once, you just instantiate
the behavior again instead of copy-pasting the annotation. Annotations
aren't really the best thing when it comes to avoiding code
duplication. And besides that, they are typically string based and
thus don't refactor as well with IDEs as normal classes do.
For the sake of clarity: in this code
myFavoriteDiv.add(new AjaxEventBehavior("onmouseover") {
protected void onEvent(final AjaxRequestTarget target) {
// do something
}
});
the AjaxEvenBehavior instance is *not* some kind of configuration
class, while Tapestry's annotation can be seen as a configuration
object. In Wicket behaviors (interface IBehavior) are first class
citizens that may 'enrich' components with their behavior. They can
cooperate with their host component(s) and the tag(s) that component
is attached to, they can receive events through host components and do
things like participate in header contribution. One variant of
behaviors we have are the line of ajax behaviors. A nice example of
why having components *and* behaviors is nice is
AjaxFormValidatingBehavior. Attach a behavior like that to any other
form component you want. The form component doesn't even have to have
any knowledge about such a component. And the sky is the limit with
behaviors, while a solution that chooses beforehand for annotations
limits itself to a set of predefined cases.
> And though most of these are anonymous classes, these
> don't enhance code reuse, since their definition is tied to the
> originating class implementation.
But that's critique of certain parts of Swing. We don't have that same
case much in Wicket I believe, and if there are certain cases that'd
bug you, you're always welcome to discuss improvements here.
> That said, there are considerable drawbacks to changing configuration
> through the alternative: properties. Though you reduce the scope of
> the object space required for implementation, you're limited to the
> types of behaviors that the initial developers saw fit to code.
Exactly the problem with annotations. But that's probably what you're
aiming at. With Wicket all the choices are open to individual
components. We sometimes choose for 'configuring' through overriding
methods instead of properties to avoid memory consumption for features
that are not used often.
> Perhaps a combination of both approaches might be useful. I can see
> obvious cases where annotations could be developed to accomplish the
> makework of anonymous class declaration and assignment. The
> annotation would utilize the same API as now currently exists, but
> just provide some glue-code.
If you think that's a nice way to go, just build it! :) Really, it's
quite trivial. Look at IComponentInstantiationListener
(Application#addIComponentInstantiationListener). That's the perfect
place to plug-in any runtime annotations processing you might like.
The objects are still constructing, making it dangerous functionality
for common use, but for annotation processing etc, it is perfect.
Coding that Tapestry example is maybe 30 mins work, and after that you
can use it anywhere you want.
> Every time you see an anonymous class declared and assigned, ask
> yourself if this might be accomplished through an annotation, and if
> said annotation would help save the developer time and effort.
If those anonymous classes are used only for some configuration, yes
(maybe), though just plain properties (or component metadata, did you
see that yet?) might work just as well in that case. But in my
example, a behavior is much more than just configuration, and if that
is the case I would actually see a big warning sign whenever
annotations were used instead of plain code.
> Just my .02
.04 now ;)
Eelco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
