Yes, long descriptions are supported; see the example output I showed in
the original email. And I see no reason why every option currently
offered in xml cannot be supported via either an annotation or even
better automatically by introspecting the classes.
I did want to build the annotation-handling functionality into the
existing plugin so that the two sources of info (xml config files and
doc-annotations) could be merged together. However the existing
myfaces-faces-plugin code is not well structured for that purpose; it
makes a lot of very xml-specific assumptions rather than having a
neutral "metadata" representation. I see no reason why the two couldn't
co-exist eventually, but intend to build a separate plugin first.
There is no reason why both plugins cannot be run separately, ie the
pom.xml be configured to run both. But that does lead to a lot of
inconsistency and redundancy; for example, one component will use the
annotations on a base class to determine settings for inherited
properties while another will ignore this annotation info completely and
get its data from an xml config file that contains (hopefully) the same
data but in another format. Ecch. I would therefore suggest not having
some components configured via xml and others via annotations in the
same project.
What I would like to see is core-1.1 and tomahawk use the approach I'm
suggesting here. All that is needed is to add annotations to the
existing code and move the comments that are currently in the tld-files
into javadoc comments on the appropriate fields. Optionally the property
methods can be reduced to abstract methods and the save/restore methods
removed if the generate-component-class approach is wanted.
With this approach it is possible to generate a concrete subclass with
property implementations and saveState/restoreState methods as has been
discussed earlier. I'm still not convinced about this, but can live with
it. Using annotations instead of lots of xml config files is a different
issue.
Regards,
Simon
Martin Marinschek schrieb:
> Sounds interesting. Will you support everything the XML-syntax allows
> to supply now? E.g, long descriptions?
>
> will it basically be an option which component-set wants to use which
> frontend? Then slowly every component set could decide if it wants to
> move over...
>
> How about restoreState/saveState? the getter?
>
> regards,
>
> Martin
>
> On Sun, Mar 9, 2008 at 10:20 PM, simon <[EMAIL PROTECTED]> wrote:
>
>> Hi All,
>>
>> Currently, trinidad and core-1.2 use the myfaces-faces-plugin to
>> generate tag classes, config files and component classes.
>>
>> There is some work going on to use this for core-1.1 and tomahawk too.
>>
>> As I mentioned earlier, I don't like the approach used by the current
>> myaces-faces-plugin; I think the large number of xml config files that
>> are needed is not elegant or user-friendly. I proposed using some kind
>> of "annotation" in the source to drive this process instead.
>>
>> I have been working on this recently, and have got the first steps
>> running. It's still very rough so I won't post the code, but wanted to
>> let you know what I'm working on. All feedback is welcome.
>>
>> Here's an instrumented UIData class from core-1.1:
>>
>>
>> /**
>> * Represents a component which has multiple "rows" of data.
>> * <p>
>> * The children of this component are expected to be
>> ...
>> *
>> * @mfp.component
>> * type = "javax.faces.Data"
>> * family = "javax.faces.Data"
>> * defaultRendererType = "javax.faces.Table"
>> * desc="tabular data"
>> */
>> public class UIData extends UIComponentBase implements NamingContainer
>> {
>> ...
>> /**
>> * Set the name of the temporary variable that will be exposed to
>> * child components of the table to tell them what the "rowData"
>> * object for the current row is. This value must be a literal
>> * string (EL expression not permitted).
>> *
>> * @mfp.property literalOnly=true
>> */
>> public void setVar(String var)
>> {
>> _var = var;
>> }
>> }
>>
>> The code I've got so far just scans the source code to build up a
>> "meta-data structure" holding the relevant data. This would then be used
>> to drive the file-generation step, hopefully reusing the existing code
>> from the myfaces-faces-plugin. In other words, I'm proposing replacing
>> the "front end" of the plugin but not the back-end.
>>
>> Dumping the parsed data gives:
>>
>> --dumping artifacts--
>> == Component
>> class:UIData
>> type:javax.faces.Data
>> prop:setVar
>> class:java.lang.String
>> isLiteral:true
>> desc:Set the name of the temporary variable that will be exposed to
>> child components of the table to tell them what the "rowData"
>> object for the current row is. This value must be a literal
>> string (EL expression not permitted).
>> --dumped artifacts--
>>
>>
>> Note that the javadoc comments from the class are taken into the
>> metadata. So comments in the component, the generated tag-class and the
>> taglib file are automatically identical and are maintained in the
>> *normal* manner for java developers.
>>
>> Also, the property type is automatically inferred from the method
>> declaration, rather than needing to be specified in xml. By the way, the
>> fact that we need a method to attach the @mfp marker to does not mean
>> that we need an implementation; an abstract method would be fine if
>> code-generation is being used to then create a concrete subclass.
>>
>> Possibly some of those attributes on the @mfp.component tag could be
>> made optional by applying standard patterns, eg looking for a public
>> static field with name "COMPONENT_TYPE" on the class.
>>
>>
>> Notes:
>>
>> * The code uses the codehaus QDOX library.
>> * java15 annotations are not used because
>> (a) we want to support 1.4
>> (b) java15 compile-retention annotations are not nice to work with
>> (c) we explicitly want the javadoc comments
>>
>>
>> Regards,
>> Simon
>>
>>
>>
>
>
>
>
