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
