While this is undeniably convenient, it deserves more thought and discussion before accepting as part of 1.2. I don't think it's a good idea as it stands. Item 35 of Josh Bloch's Effective Java (2nd edition) is "Prefer annotations to naming patterns". One of the great strengths of Java is its type-safety, an important reason why Java is such a good choice for production web services. Naming patterns rely on conventions that are invisible to the compiler; they throw away the opportunity to enforce typing rules at compile time. The use of metadata (annotations), by contrast, lets the compiler work for you by catching type problems early.
I'm talking specifically about using method-level annotations instead of method naming patterns in the case of Resource methods related to variant representations. I'm not trying to take this line of reasoning any farther. For example, while I'm not crazy about allow* and handle*, at least that's in Handler, not Resource, and even there Restlet *does* define the standard methods (Get/Put/Post/Delete/Head/Options) explicitly. --tim On Fri, Jan 16, 2009 at 9:05 AM, Jerome Louvel <[email protected]>wrote: > To illustrate the new feature, here is the test resource class that I > used in the unit test: > > *public* *class* AutoDetectResource *extends* Resource { > > * public* Representation representXml() { > * return* *new* StringRepresentation("<root>test</root>", > MediaType.*TEXT_XML*); > } > > * public* Representation representHtmlEn() { > *return* *new* StringRepresentation("<html>test EN</html>", > MediaType.*TEXT_HTML*); > } > > * public* Representation representHtmlFr() { > *return* *new* StringRepresentation("<html>test FR</html>", > MediaType.*TEXT_HTML*); > } > > } > No need in this case to override the constructor, to update the variants' > list or to manually handle the dispatching! > >
