Hi,
maven-faces-plugin used for autogeneration in its current form is NOT
sufficient to generate whole components (mainly tomahawk's ones) -
there's no method to e. g. generate initial values for properties in
component's code.
What i miss most is possibility to use own implementations of extra
methods, overiding default autogenerated setters/getters or enabling own
state storing/restoring methods (for highly customized components like
DataTable).
I suggest one of these two approaches:
(a) not generating whole code (source for class file), but using similar
approach used in legacy generator - generating only portion of class
between special comments in code (and in the end having full source
available for modifications).
(b) use extra template with CDATA type with java source fragment outside
autogeneration
I'd rather choose approach in (a), because modifing fragment in approach
(b) would be much harder (seeing errors only after trying to build whole
myfaces).
Best regards,
Zdenek Sochor
Bruno Aranda napsal(a):
Hi there,
As you may know there has been some work towards the complete
implementation of JSF 1.2. For this new version of MyFaces, all the
components from the basic renderkit are autogenerated using Trinidad's
maven-faces-plugin, which has been adapted to generate components
fully complicant with the spec. The generators for the core converters
and validators is still missing. This plugin, also generates the
faces-config.xml file and the taglib files, and, if wanted, a facelets
taglib too.
So, at this point, the html taglib (h) is fully autogenerated. There
is an issue with the generation of the faces-config.xml file, where 25
identical renderkits are generated (yes, as many as renderers). I
still don't know the reason for that, but this should´nt make the
application fail.
There is a legacy core taglib (f) being used now, but this will be
eventually converted as well.
Most of the requirements for 1.2 at the API level has been implemented
as well (I am not sure what remains to be implemented, but the TCK can
help with that), such as a new base tag that allows to interweave jsp
and jsf code without having to use verbatim tags for instance,
postback management, Value/MethodBindings are now
Value/MethodExpressions for the components, etc...
However I just tried to build the blank application with the new
MyFaces 1.2 files but this is not possible yet. The application starts
ok, but there is an conversion or rendering problem when the first
page loads, which I haven't got time to investigate.
So, if we are able to start the blank application with the jars, and
then run the TCK to see what is missing, we will be able to have
MyFaces 1.2.
Another important thing is that the original branch for MyFaces 1.2 is
very old. There will need to be an important merge effort with the
current trunk to fix all the bugs that we have detected since then.
I am on holidays for the christmas period, so I will not be able to
continue with this after next year. I would be very happy to see more
developers with this, as MyFaces 1.2 is a *very* important milestone
for the project.
Cheers!
Bruno