What do you think of this use of annotations?To make a simple class available for remote access, use the @Create and @RemoteMethod annotations:
@Create public class RemoteFunctions { @RemoteMethod public int calculateFoo() { return 42; } }To make simple bean classes available for remote access, use the @Convert and @RemoteProperty annotations:@Convert public class Foo { @RemoteProperty private int foo; public int getFoo() { return foo; } @RemoteProperty public int getBar() { return foo * 42; } }
-
DWR 2.0M2 adds annotation support (14 messages)
- Posted by: Joseph Ottinger
- Posted on: May 26 2006 12:11 EDT
Continuing the wave of annotation support for developers from all kinds of libraries, Maik Schreiber has has added annotation support to DWR, which released the functionality in the second milestone release of DWR 2.0. Exposing functionality via AJAX is now a matter of adding @Create and @RemoteMethod.Threaded Messages (14)
- I think... by Constance Eustace on May 26 2006 12:45 EDT
- Re: I think... by Joe Walker on May 26 2006 13:39 EDT
- Re: I think... by Patrick Angeles on May 26 2006 19:15 EDT
- Re: I think... by Phil Zoio on May 27 2006 06:53 EDT
-
Re: I think... by Alexandre Poitras on May 28 2006 10:24 EDT
- Re: I think...declarative is not what annotations are by Constance Eustace on May 30 2006 02:15 EDT
-
Re: I think... by Alexandre Poitras on May 28 2006 10:24 EDT
- Re: DWR 2.0M2 adds annotation support by Henrique Steckelberg on May 26 2006 13:02 EDT
- Re: DWR 2.0M2 adds annotation support by Joe Walker on May 26 2006 13:36 EDT
- Re: DWR 2.0M2 adds annotation support by gary bogachkov on May 26 2006 02:15 EDT
- Re: DWR 2.0M2 adds annotation support by Joe Walker on May 26 2006 13:36 EDT
- Implementation could be cleaner by Matt Raible on May 26 2006 15:08 EDT
- Re: DWR 2.0M2 adds annotation support by Joe Walker on May 29 2006 11:11 EDT
- Here is my proposal by Mats Henricson on May 31 2006 04:26 EDT
-
Re: Here is my proposal by Joe Walker on June 04 2006 04:06 EDT
- The problem with @Create by Mats Henricson on June 04 2006 04:38 EDT
-
Re: Here is my proposal by Joe Walker on June 04 2006 04:06 EDT
- Here is my proposal by Mats Henricson on May 31 2006 04:26 EDT
-
I think...[ Go to top ]
- Posted by: Constance Eustace
- Posted on: May 26 2006 12:45 EDT
- in response to Joseph Ottinger
1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation 2) This is a good use of annotations, as annotations were intended for use 3) I love DWR, at least until I read up on the google toolkit more. -
Re: I think...[ Go to top ]
- Posted by: Joe Walker
- Posted on: May 26 2006 13:39 EDT
- in response to Constance Eustace
1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation
You can still configure DWR using dwr.xml, and sometimes this will be the prefered option. Having a centralized configuration point makes audit easier. On the other hand Annotations are easier to use. Joe. http://getahead.ltd.uk/dwr/
2) This is a good use of annotations, as annotations were intended for use
3) I love DWR, at least until I read up on the google toolkit more. -
Re: I think...[ Go to top ]
- Posted by: Patrick Angeles
- Posted on: May 26 2006 19:15 EDT
- in response to Constance Eustace
1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation
You *could* use annotations for configuration, but that would be poor use of it. You could just as easily use properties files for code: sql.query=SELECT * FROM ACCOUNT ---- stmt.execute (props.get("sql.query")) ; Is that a good reason to hate properties files because they're used for code? And for what it's worth, the separation between code and data (ergo configuration) is really arbitrary, and the art of programming is knowing where to draw that line. -
Re: I think...[ Go to top ]
- Posted by: Phil Zoio
- Posted on: May 27 2006 06:53 EDT
- in response to Constance Eustace
1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation
On the whole I think there are two types of uses for annotations. The first is as a replacement for configuration - which can make your applications more compact, at the expense of a little less flexibility, as you rightly observe. The second is to replace code that you would otherwise have to write. In Strecks (a set of Java 5 extensions to Struts based largely on annotations - see http://strecks.sourceforge.net/), I am using annotations to replace code, and also to wire up the application in ways that would not be possible without annotations, at least not in a very intuitive way. Viewing annotations as only purely a replacement for XML configuration is quite narrow. Phil Zoio http://www.realsolve.co.uk/ -
Re: I think...[ Go to top ]
- Posted by: Alexandre Poitras
- Posted on: May 28 2006 10:24 EDT
- in response to Phil Zoio
I have said it many times : 1) Use annotations for declarative programming. 2) Prefer XML for configuration (or Java if the configuration is dynamic and necessitate some conditionnal logic). Of course, the line is sometimes flew behind the two but it's a good starting point. Since this is declarative programming, I think this is a great use of annotations.1) I hate annotations, it is configuration inside of code, thus preventing the changing of configuration without compilation
On the whole I think there are two types of uses for annotations. The first is as a replacement for configuration - which can make your applications more compact, at the expense of a little less flexibility, as you rightly observe.
The second is to replace code that you would otherwise have to write. In Strecks (a set of Java 5 extensions to Struts based largely on annotations - see http://strecks.sourceforge.net/), I am using annotations to replace code, and also to wire up the application in ways that would not be possible without annotations, at least not in a very intuitive way.
Viewing annotations as only purely a replacement for XML configuration is quite narrow.
Phil Zoio
http://www.realsolve.co.uk/ -
Re: I think...declarative is not what annotations are[ Go to top ]
- Posted by: Constance Eustace
- Posted on: May 30 2006 14:15 EDT
- in response to Alexandre Poitras
http://en.wikipedia.org/wiki/Declarative_programming Declarative programming only really has benefits when the programming environment has one key aspect: it's interpreted (Ruby, etc) or dynamically compiled (JSP). JAVA IS NOT EITHER OF THOSE. If you change one of the declarative/annotative sections in Ruby or JSP (assuming its not an include...argh, or did they fix that?), boom, next execution of the code, its fixed. But core java classes must be recompiled, jar/ear/war packaged, server deployed (I'm assuming a hot deploy to be nice). That's not declarative programming. It also opens up the whole Domain-Specific Language pandora's box. Sure, DSLs can provide compact syntax, but from a code maintenance standpoint, they also allow infinite numbers of dialects directly injected into Java. I have the same issues with the infinite numbers of JSP Taglibs out there. Java, despite its fragmented, multi-toolkit/framework state, has lots of basic paradigms shared across those frameworks, so picking them up is relatively basic. -
Re: DWR 2.0M2 adds annotation support[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: May 26 2006 13:02 EDT
- in response to Joseph Ottinger
First, why 2 different annotations (@create and @convert) for similar results? Second, aren't these 2 annotation names too short/simple, with a much higher risk of name clashing with other annotation libraries? -
Re: DWR 2.0M2 adds annotation support[ Go to top ]
- Posted by: Joe Walker
- Posted on: May 26 2006 13:36 EDT
- in response to Henrique Steckelberg
First, why 2 different annotations (@create and @convert) for similar results?
There are 2 quite different things that DWR does with your objects. @Create allows objects of the given type to be created and the methods remoted. @Convert allows objects of the given type to be marshalled from Java to Javascript.Second, aren't these 2 annotation names too short/simple, with a much higher risk of name clashing with other annotation libraries?
The good news is that annotations are used by import statements so there is namespacing for them. Joe. -
Re: DWR 2.0M2 adds annotation support[ Go to top ]
- Posted by: gary bogachkov
- Posted on: May 26 2006 14:15 EDT
- in response to Joe Walker
I agree with Henrique's point Even if import statements give you namespacing, modern IDEs provide import-shortcuts (like "Organize Imports" in eclipse, or automatically importing when you use code completion for the class/annotation type) that make it pretty easy to import the wrong package once in a while (and annoying at other times when you have to consistenly pick the type from a drop down box). Also, if for some reason you do have a class that uses two seperate annotations called.. say... @RemoteProperty - you will have to fully qualify their types in each declaration. (Obviously if you're using a templating style for creating new classes or use few libraries - this isn't that much of an issue.) In any case, this isn't the biggest deal one way or the other - but since you don't have backwards-compatibility issues to worry about at this point, why not call these annotations something that plays nice from the beginning? ideas: Simple variation: @DWRCreate, @DWRemoteMethod, @DWRConvert, @DWRemoteProperty.... Or here are even better psssibilities in my opinion: @Create ->@AjaxRemoteClass or @DWRClass or @DWRLogic or @DWRCallable @RemoteMethod ->@AjaxRemoteMethod or @DWRMethod @Convert ->@AjaxBean or @DWRBean (I would have this with a field called exposeAllProperties=true/false that defaults to false, since -from personal experience- i have found it annoying to have to type out the same annotation for multiple properties in a bean (although obviously some times you really do only want to expose specific properties, which is why I would default it to false) @RemoteProperty ->@AjaxProperty or @DWRProperty -my 3 cents Gary B -
Implementation could be cleaner[ Go to top ]
- Posted by: Matt Raible
- Posted on: May 26 2006 15:08 EDT
- in response to Joseph Ottinger
While I like this idea, the implementation seems like it could be better. If I choose to use DWR annotations, I still have to specify which classes are annotated in web.xml. One of the reasons folks like annotations is because they give you better refactoring support. Continuing to require configuration in XML files somewhat negates this. Of course, if you're using IDEA, their refactoring supports parsing/changing your XML files, so it's somewhat of a moot point. AFAIK, Eclipse still does not support refactoring w/in XML files. Holy sh** - there's a fricken' preview button! -
Re: DWR 2.0M2 adds annotation support[ Go to top ]
- Posted by: Joe Walker
- Posted on: May 29 2006 11:11 EDT
- in response to Joseph Ottinger
dwr.xml support is still available, and I have to say prefered by me because it is a central audit point that helps security. So assuming that answers everyone that says "Annotations are Evil", what can we do to make our implementation better? We could search the entire class hierachy for classes with annotations to answer Matt's point. Might be slow. Is there a better way to do this? The reason we chose Create and Convert was to match the element names in dwr.xml. Is name clashes really a problem? -
Here is my proposal[ Go to top ]
- Posted by: Mats Henricson
- Posted on: May 31 2006 04:26 EDT
- in response to Joe Walker
Hi! I think it is better to have annotations look like this: @DWRClass(create=session) public class RemoteFunctions { @RemoteMethod public int calculateFoo() { return 42; } } If none of the public functions are annotated with @RemoteMethod, then all of them are exposed. "create" is an enum with the values {application,session,request,page}. One of them should be default. Not sure which. Joe should know. I'm willing to discuss this further, because I think the current proposal is a naming mistake. Big mistake! Mats -
Re: Here is my proposal[ Go to top ]
- Posted by: Joe Walker
- Posted on: June 04 2006 16:06 EDT
- in response to Mats Henricson
Hi!
My reasoning was as follows: - having the same naming between dwr.xml and @Annotaions is a good thing - although dwr.xml naming is not perfect (particularly ) it isn't too bad. My current feeling is that is isn't broken enough to need fixing. - Naming clashes are not an issue because there is package scoping to annotations anyway. What did I get wrong?
I think it is better to have annotations look like this:
@DWRClass(create=session)
public class RemoteFunctions {
@RemoteMethod
public int calculateFoo() {
return 42;
}
}
If none of the public functions are annotated with @RemoteMethod, then all of them are exposed. "create" is an enum with the values {application,session,request,page}. One of them should be default. Not sure which. Joe should know.
I'm willing to discuss this further, because I think the current proposal is a naming mistake. Big mistake!
Mats -
The problem with @Create[ Go to top ]
- Posted by: Mats Henricson
- Posted on: June 04 2006 16:38 EDT
- in response to Joe Walker
The problem I have with the @Create annotation is that it isn't possible to understand by itself. The case in dwr.xml is different, because there you have a context. The element in dwr.xml can be understood by the fact that it exists in the dwr.xml context, i.e. if you see , then you know it has something to do with DWR by the mere fact that it exists in the dwr.xml file. This is not the case for the @Create annotation. It can be added to ANY class, so what am I to expect if I see it added to a class? I would be bewildered! Create what? Also, I still don't understand what it means. Of course an object must be Created for its member functions to be used, but is it per session, per call, or what? Also, @Create is a verb. Most annotations I've seen so far are adjectives or substantives. It think that is also a hint that @Create isn't a good choice. I have tons of them listed here: http://www.crisp.se/utbildning/StateOfTheArtInServerSideJava.pdf Mats