On Sat, 2008-03-15 at 15:25 -0500, Leonardo Uribe wrote:
> Why not create some code that scan abstract component sources and
> create xml files with the info and give this info to
> myfaces-faces-plugin? on build project there are some files like
> javax.faces.component hierarchy and all necessary info
> should be on abstract component classes.
I'm not quite sure what you are suggesting here.
I did initially try to just "enhance" the existing plugin with support
for annotations rather than rewrite it but couldn't get that to work.
The build module is something that is built *before* the api and impl
jars. So there is no way to feed information from the source back into
the build module.
I guess the build module could have "partial" information, and then the
missing bits be filled in when the api or impl projects are built. But
that sounds even harder to understand than having everything in the
build module. For example, if we annotate the UIInput class to add info
about the "immediate" property, then presumably that info should not be
present in the .xml files in the build project. But wouldn't that have
some very weird consequences?
In addition, the code in the myfaces-faces-plugin is really ugly. I
cannot believe that the "class generation" is done like this:
if (property.isLiteralOnly() || property.isTagAttributeExcluded()){
//If the property is literal or is tagAttributeExcluded,
//the default value goes on the definition of the field
out.println("private " + propertyClass + propertyGenerics + " "
+
fieldPropName + (def == null ? ";" : " = " + def +
";"));
}else{
//If is a primitive class, has a set field to check if this
//property is defined, so the default value goes on the
//getter method.
//If is a class, the same applies, because the check
//is against null
out.println("private " + propertyClass + propertyGenerics + " "
+
fieldPropName + ";");
}
This should really be template-based so that changes don't require
understanding, modifying and re-releasing the build plugin.
Regards,
Simon
