Hi Tal, Again, if there is no annotation declared on a ServerResource subclass, there is nearly no cost for testing for the presence of those annotations. Hence, it is not really necessary to call setAnnotated(false). I don't want to add a new annotation for this. The fact that a class is a resource is based on the class hierarchy (extending ServerResource), no need to mark it with an additional annotation IMO. Regarding other annotations, I don't want to go further on the JAX-RS road. I really don't see the issue of calling a setter method to turn off conditional processing, otherwise we risk using annotations as the programming language. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : dimanche 12 avril 2009 22:08 À : discuss@restlet.tigris.org Objet : Re: Annotations and Restlet's future Hi Jerome, How about instead of calling setAnnotated(false), there would be an annotation to turn annotation on? Since this doesn't seem like behavior you'd want to turn on or off during the life of the resource instance, it seems like it should be defined at the class level, not in the instance. Makes sense? Maybe something like this: @Resource class ArticleResource extends ServerResource { @Get("txt") ... } The @Resource tag could also support parameters defining general characteristics of the resource. Perhaps enabling conditional mode, etc. Maybe it can even be a separate tag, such as @ConditionalResource. What I'm hoping is that if this tag is not present, annotated mode would be off, which is what I think should be the default. -Tal Jerome Louvel wrote: Hi all, I haven't fully digested all this feed-back, but it helps tremendously! Just to clarify a few points: * Rob correctly guessed my thoughts, annotations should be a fully optional feature * I like to have this feature turned on by default because it lowers the barrier of entry for new users. For experienced Restlet developers, it's easy enough to override the "doInit()" method and call "setAnnotated(false)". * Non-annotated resources shouldn't impose any significant performance hit, even if the "annotated" flag is turned on (annotation detection is done only once) * No additional annotation is expected in Restlet 1.2, we should stick with the current 5 public annotations * Exceptions are no rethrown for annotated methods Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com> http://www.noelios.com _____ De : Rémi Dewitte [mailto:remidewi...@gmail.com] Envoyé : vendredi 10 avril 2009 08:58 À : discuss@restlet.tigris.org Objet : Re: Annotations and Restlet's future Hello, I thank you all to clear my mind about annotations. Annotations are probably good to get started with a hello world or minimize the amount of code you would write. But you lose some compilation checks and moreover developing further more complex resources will require to understand how it works (routing/switch logic) and which methods will not be called because of the use of annotations. If I want to search for resources class will I have to search for @Resource as well ? How far are we from annotated Restlets ? Would it be possible to have ServerResource free of annotation logic and an AnnotatedServerResource subclass removing the need for isAnnotated ? Cheers, Rémi On Thu, Apr 9, 2009 at 17:47, Rob Heittman <rob.heitt...@solertium.com> wrote: GWT 1.5/1.6 is happy with annotations at compile time ... but if the implementation needs to examine them at runtime via reflection, GWT doesn't have that capability. GWT getClass() emulation doesn't have getAnnotations() ... or much of anything else. There's no reflection in the Javascript room. Restlet 1.2's current incarnation is fine with me ... annotations optional. But I agree that the non-annotation and annotation approach should use the same vowels and consonants in the same order whenever possible :-) This helps us bears of very little brain. On Thu, Apr 9, 2009 at 7:06 AM, Tim Peierls <t...@peierls.net> wrote: On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman <rob.heitt...@solertium.com> wrote: ...my only *strong* requirement, that the annotation based solution must remain a voluntary choice and not the only way to get things done. It should remain possible to achieve whatever annotations can achieve in a non-annotation way. This allows the basic API outline to work in places where annotations are not available or work differently enough to cause friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala ...) It is OK with me if the non-annotation approach requires verbosity or heavy lifting, it just needs to exist. Isn't that currently the case with the 1.2 branch? (Does GWT not support annotations yet? I thought it did.) It would be best if the non-annotation approach used the same terminology as the annotations, and I think that's not the case right now. --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1742186
