Hi Matthias,
Thanks for reminding me about Tobago. I did mean to have a look at their
configuration-handling, but had not got around to it. I have spent the
last hour or so looking at it, and here's a brief summary.
The tobago-tool-annotation module defines a bunch of source-retention
annotation classes. The tobago-tool-apt module then defines a library
that uses the com.sun.mirror.apt apis to define annotation-processor
classes. And the myfaces-apt-plugin module then defines a maven2 plugin
that builds a commandline and execs the external sun "apt" commandline
tool to apply the annotation-processor classes to the source.
The result is of course that the faces-config.xml and
facelets.tabglib.xml files can be generated from the source. This is
quite similar to what I am proposing.
Note that Tobago does write tag classes "by hand" rather than generate
them; this does mean it needs a bit less metadata than we do (I think
we're all agreed on generating tag classes at least).
I did consider using apt earlier, and decided not to. The main reasons
are:
(a) requires the sun apt tool to be on the build machine
(b) requires executing an external process (ecch)
(c) does not provide access to the javadoc attached to classes, methods
and fields.
In addition, the .class files must be 1.5-or-later format. I think
Tobago uses retroweaver to then make them 1.4-compatible.
Using QDOX and "doclet annotations" rather than real annotations seems
nicer here. IDE tool support for the annotations is lost, but in all
other ways it seems to work out better. It's a shame that
source-retention annotations aren't supported better; they *should* be
able to do all that qdox can, and *should* have a standard api to handle
them. Hopefully one day a JCP will fix this, but for the moment, they
just suck.
So in short: what I'm proposing is about half-way between what Tobago
does (annotation-driven) and what the myfaces-maven-plugin does (richer
metadata to allow code generation).
Regards,
Simon
On Mon, 2008-03-10 at 09:04 +0100, Matthias Wessendorf wrote:
> 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
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>
>
>
