-Igor
On 8/1/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i thought element was the page relative path of the component you want to bind the listener to, so it would be something like "foo:bar:MyFavoriteDiv". how does the classname here help you? in this case no refactoring tools know about wicket component paths nor can they deduce them at compile time.
-IgorOn 8/1/06, Julian Klappenbach < [EMAIL PROTECTED]> wrote:True, but if you're making the case based on refactoring tools
provided by the best of our IDEs, I know of at least two that can be
instructed to search for string values to include in the search. In
this case the annotation would need to feature fully qualified
classnames:
@EventListener(element="org.foo.MyFavoriteDiv", event="onMouseOver",
method="onEvent")
This is an abstract example. I'll work on some concrete examples as I
discover them and if they have merit, I'll present them to the list.
On 8/1/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> my only big problem with this is the "soft" bindings that are required by
> annotations
>
>
>
> @EventListener(element=
> > "myFavoriteDiv", event="onMouseOver", method="onEvent")
>
>
>
> in this case "myFavoriteDiv" and "onEvent"
>
> "myFavoriteDiv" would have to be the relative path of the component, so if
> you change the hierarchy in any way you might break the annotation again.
>
> strings dont stand up to refactoring so things will break without a warning
> just because you renamed a variable or the framework renamed a method. i
> dont know about everyone else but i refactor a lot. i am an incremental
> developer, write a rough first cut and then evolve the code. i hardly ever
> get variable names completely right the first time so i like to go and
> rename them to something more appropriate after the code is up and running.
>
> sometimes i forego using propertymodels for a simple abstractmodel. yes it
> is very wordy in java, but i know it wont break on me because someone
> renamed a property somewhere.
>
> -Igor
>
>
>
> On 8/1/06, Julian Klappenbach < [EMAIL PROTECTED]> wrote:
> > 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
