Hi,
On Mon, Mar 10, 2008 at 8:54 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 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.
have you also looked at Tobago?
They currently use @nnotations to (at least) generate the required
XML for faces-config / facelets
-Matthias
>
> 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
> >>
> >>
> >>
> >
> >
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
