Here I have to disagree, although in process only. Although the
latter case which you give is a purist example, it's makework. It's
using subclassing to override behavior -- one OO philosophy behind
Swing that I think is not always a positive strategy. Especially in
the case where subclassing can be satisfied through anonymous classes.
And though I know I'm risking a fight here, I know my opinion is
valid.
I've developed projects based on Swing. For every component that I
need to configure, there's a host of classes that I need to override
to provide the behavior or look and feel that I desired. This is the
purist OO approach, and though I'm not averse to the effort of
implementation, I am concerned by the size of the object space that's
required by the philosophy. When every panel or control requires a
host of a dozen or so objects to configure it, a large application can
easily find itself with hundreds of objects with the sole purpose of
configuration. And though most of these are anonymous classes, these
don't enhance code reuse, since their definition is tied to the
originating class implementation.
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.
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. And if you didn't want to use
annotations, the API is right there waiting for you. The prior
example, honestly, was a good case.
This:
// Notice I enhanced the annotation signature to include the method
for invocation
@EventListener(element="myFavoriteDiv", event="onMouseOver", method="onEvent")
public void onEvent()
{
// do something
}
coud easily compile down to:
myFavoriteDiv.add(new AjaxEventBehavior("onmouseover") {
protected void onEvent(final AjaxRequestTarget target) {
// do something
}
});
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.
Just my .02
Julian Klappenbach
Architect / Development Lead
Ramp Technology Group
mailto:[EMAIL PROTECTED]
http://www.rampgroup.com
On 8/1/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> It's a nice feature... for Tapestry. We don't need such use of
> annotations because we have 'just Java objects' to do stuff like that.
> For instance, Wicket's equivalent of:
>
> @EventListener(elements = "myFavoriteDiv", events = "onMouseOver")
> public void watchText()
> {
> // do something
> }
>
> is:
>
> myFavoriteDiv.add(new AjaxEventBehavior("onmouseover") {
> protected void onEvent(final AjaxRequestTarget target) {
> // do something
> }
> });
>
> If you ask me, that's more object oriented, and I like the fact that
> it is plain Java (thus no Java 5 needed).
>
> Also, an advantage of using objects over annotations is that
> AjaxEventBehavior can be extended and easily customized for reusable
> behaviors. Annotations weren't build with that in mind.
>
> Wicket 1.3 - when we start on that - will still be Java 1.4 based,
> like any 1.x will be. Wicket 2.0 (see trunk) is based on Java 5. We
> might use annotations if we have a good reason to do so, but currently
> we mainly use Java 5's generics support to allow you to create typed
> models and components.
>
> Eelco
>
>
>
> On 01 Aug 2006 12:51:47 -0700, Sean Sullivan <[EMAIL PROTECTED]> wrote:
> >
> > This is an innovative feature in Tapestry 4.1:
> >
> > http://tapestry.apache.org/tapestry4.1/ajax/EventListener.html
> >
> > Is the Wicket framework going to adopt annotations? Will annotations be
> > included with Wicket 1.3?
> >
> > Sean
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
