You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bruno Aranda <br...@gmail.com> on 2006/12/21 13:19:57 UTC
MyFaces 1.2 Update
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.2files 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
Re: MyFaces 1.2 Update
Posted by Zdeněk Sochor <zd...@ataco.cz>.
Hi Bruno,
i looked at plugin and i found <default-value> for components
(<initial-value> is ignored, but defined).
I attached class source for Tomahawk's DataTable (with autogenerated
code between comments and .xml definition) which CANNOT be generated
with plugin due to problem:
(a) state saving/restoring methods are customized and plugin doesn't
offer providing own implementation in template
Second issue i had - own implementation of getters/setters is already
resolved, even if little tricky - adding to "ignored" method list by
specifying it with "magic comment" with real comment:
/**///methodName
- only method name must be specified, because generator compares only
name, not whole definition:
/**///public void setProp(String value)
won't work
/**///setProp
WILL work
But to make template compilable it would require to add property
definition in "magic comment" w/o real comment e. g.
/**/String _prop;
If the plugin is extended to support own implementation of state dealing
methods in templates, those templates would require to contain all
properties (autogenerated) to be able to compile standalone. This in the
end would degrade whole purpose of generator in its current form
(generating whole files).
Cheers,
Zdenek
Bruno Aranda napsal(a):
> Well, AFAIK all what you mention in your mail IS handled by the
> maven-faces-plugin (from the trinidad 1.2 branch). It is possible to
> set the initial values (this is done for some of the html basic
> renderkit components), I cannot check the code right now but you can
> define a <initial-value> tag in the property XML file for your
> component, and the generated component from this XML file with have
> that initial value.
> As for partial autogeneration, you can use component "templates" that
> contain code that will be merged with the result of the generator.
> Those templates file do compile to ease the development. I think that
> UICommand from the myfaces core is generated this way. Take a look at
> the myfaces-build module of the myfaces 1.2 branch that contains the
> XML files as well as the component templates.
> I think that, at this point, the whole tomahawk components classes and
> tag classes could be generated using this mechanism, but I would wait
> to the complete implementation of myfaces 1.2.
> Hope I have answered your concerns,
>
> Cheers,
>
> Bruno
>
>
> On 22/12/06, *Zdeněk Sochor* <zdenek.sochor@ataco.cz
> <ma...@ataco.cz>> wrote:
>
> 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
>
>
>
Re: MyFaces 1.2 Update
Posted by Bruno Aranda <br...@gmail.com>.
Well, AFAIK all what you mention in your mail IS handled by the
maven-faces-plugin (from the trinidad 1.2 branch). It is possible to set the
initial values (this is done for some of the html basic renderkit
components), I cannot check the code right now but you can define a
<initial-value> tag in the property XML file for your component, and the
generated component from this XML file with have that initial value.
As for partial autogeneration, you can use component "templates" that
contain code that will be merged with the result of the generator. Those
templates file do compile to ease the development. I think that UICommand
from the myfaces core is generated this way. Take a look at the
myfaces-build module of the myfaces 1.2 branch that contains the XML files
as well as the component templates.
I think that, at this point, the whole tomahawk components classes and tag
classes could be generated using this mechanism, but I would wait to the
complete implementation of myfaces 1.2.
Hope I have answered your concerns,
Cheers,
Bruno
On 22/12/06, Zdeněk Sochor <zd...@ataco.cz> wrote:
>
> 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
>
>
>
Re: MyFaces 1.2 Update
Posted by Zdeněk Sochor <zd...@ataco.cz>.
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