Hi Andrew,
Andrew Robinson schrieb:
> One major drawback to the javadoc annotation approach has been left
> out and that is attribute reuse. The maven-faces-plugin allows you to
> import XML fragments using XPath. So in Trinidad, onclick,
> onmouseover, onmouseout, etc. you can import one XML file and not have
> to re-define all these. But with the javadoc approach, you have to
> either one, try to hack the code to extend other classes, two have
> some weird interface usage to import these. Either way, the object
> hierarchy has to be hacked to get it to work.
>
Hmm..interesting. So trinidad has cases where a class X is not related
to A by inheritance, but does want to provide the same properties as A?
Java currently defines "implements" and "extends"; sounds like Trinidad
has invented a new OO concept, "emulates" :-).
While I haven't analysed this carefully, I see no reason why there
couldn't be an extra annotation attribute:
/**
* @mfp.component emulates="javax.faces.UIData" ...
*/
class TrinidadData .. {...}
which would cause the plugin to look up the metadata for the
javax.faces.UIData component then simply copy all the property
definitions for that class into the metadata for the TrinidadData class.
Would that satisfy the trinidad requirement?
> Also, the java-annotation-javadoc approach is odd that code must be
> filled in. The Java files would have some sort of attribute
> definitions, but no body (I don't want to have to waste time writing
> setters & getters when I should only have to write a definition for an
> attribute).
>
Yes, there does need to be something to attach property annotations to.
I would suggest an abstract getter method:
/**
* An identifier for this component which is unique within the
enclosing NamingContainer.
*
* @mfp.property literalOnly=true
*/
public String getId();
rather than annotating a private class member. After all, there might
not *be* a real class member; the data might be stored in the
attributes map for example. This is shown in the first property example
here [1]:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
By defining the getter method as above, the plugin can inspect the
return type to determine the property type automatically (so the
annotation doesn't have to specify it). I guess it is possible to do
away with the method completely, and just have a free-standing
annotation, but (a) that look weird, and (b) the annotation has to be
more complex because we have to explicitly provide property name and
type rather than looking at the method definition.
Note that because the method is defined as a normal java method, code in
a renderer (for example) can be written to call that method and will
still compile even before the code-generator has been run. Not critical,
but nice.
I don't see any need to define the corresponding setter method.
Just in case it isn't clear, the javadoc above can be used as the
property description field for the tld (first sentence -> short
description, and the remainder for long description).
Is this more work than defining the equivalent xml?
[1] I'm not sure what the later property examples on that page are meant
to be; as Leonardo has written them they are attached to no function
which is not what I had in mind...
> Personally, I much prefer the Trinidad approach, and I have found it
> easy to use, except for the *Template files (there has to be a better
> way than that as they are not IDE friendly).
>
Regards,
Simon
