|
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
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 <[email protected]>
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 <[email protected]>
wrote:
On Thu, Apr 9, 2009 at 4:57 AM, Rob
Heittman <[email protected]>
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
|
