i also agree with what eelco said. we concentrate on the pure java approach and if there is an improvement that annotations can bring we will first build that functionality in java and bridge it with an annotation so users can use whichever way they want.
-Igor
On 8/1/06, Julian Klappenbach <[EMAIL PROTECTED]> wrote:
True, I had not taken into account the page relative path. Again, if
I can find concrete examples, I'll present them to the group. I have
had a lot of success with the EJB3 annotation model, and in turn, I
can see many cases where the Swing development process could benefit
from annotations. Though opportunity for annotations may not
translate as well to Wicket, the promise of reduced effort is, at
least to me, too attractive to dismiss offhand.
On 8/1/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> furthermore the path is not enough...what if you swap MyFavoriteDiv with
> some other panel? what is then the expected behavior? should the listener
> still be bound? or no? how do you configure? it just gets messy imho for
> this particular example.
>
> -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.
> >
> >
> > -Igor
> >
> >
> >
> > On 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
