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
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
