myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: build plugin - an alternative annotation approach
Date Mon, 10 Mar 2008 08:04:30 GMT
Hi,

On Mon, Mar 10, 2008 at 8:54 AM, simon.kitching@chello.at
<simon.kitching@chello.at> 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 <skitching@apache.org> 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

Mime
View raw message