You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Simon Kitching <si...@chello.at> on 2008/01/30 13:39:29 UTC
myfaces-faces-plugin - architecture
Hi,
Are there any emails/design-docs available on why the trinidad build system (now myfaces-faces-plugin) was designed as it was?
Currently, it uses xml configuration files plus java "template" files to generate java classes for components. It also then generates java source for jsp taglib handlers, and config files like .tld and faces-config.xml.
Was consideration given to instead driving the process from annotations (or xdoclet tags) attached to component, converter and validator classes? It would seem to me that this would be more natural for java developers to use...
Thanks, Simon
Re: myfaces-faces-plugin - architecture
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
On Jan 30, 2008 1:53 PM, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Matthias,
> > yep.
> > -xml configuration == "mini faces-config files"
> > -templates == in order to "override" some *defaults* (like when you
> > want to do something "special" inside the validate() for InputFile,
> > provide a template, which is a real Java class)
> > -it generates the real UIComponent java file as well
> > -generates facelets XML taglib file
> >
> Is it possible to use the plugin in a way where the component/renderer
> gets not generated, only the tagblib and config stuff?
I think Lu4242 added a "comp-exclude" TAG, which possibly does that.
-M
>
> I think this is the way to go for now. I know, then the developer has to
> ensure that the types of the setter on the UIComponent do not differ to
> the property.
> Another short term solution could be to just create an abstract basis
> class with the setter/getter stuff but leave the real logic of the
> component out of it. The developer then has to inherit from this class
> the real component.
>
>
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: myfaces-faces-plugin - architecture
Posted by Martin Marinschek <ma...@gmail.com>.
Leonardo,
can you investigate into the suggestion by Mario - I think this will
be even better (and easier to achieve) then generating the components
into the source-tree, as the old MyFaces component generator did.
@Everyone: we had a generator once, you remember? It is not in use
anymore cause nobody maintained it anymore... let's settle for one
generator, please.
regards,
Martin
On 1/30/08, Martin Marinschek <ma...@gmail.com> wrote:
> Hi Mario,
>
> your second suggestion sounds viable for me - not for the API
> components, as those cannot change their inheritance, but for the
> tomahawk and MyFaces impl components, this should be doable (and a
> very good idea) indeed.
>
> @why Trinidad doesn't work with annotations: how would you then
> generate restoreState and saveState? And the getters? You don't want
> to write all the getters by hand, do you?
>
> regards,
>
> Martin
>
> On 1/30/08, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi Matthias,
> > > yep.
> > > -xml configuration == "mini faces-config files"
> > > -templates == in order to "override" some *defaults* (like when you
> > > want to do something "special" inside the validate() for InputFile,
> > > provide a template, which is a real Java class)
> > > -it generates the real UIComponent java file as well
> > > -generates facelets XML taglib file
> > >
> > Is it possible to use the plugin in a way where the component/renderer
> > gets not generated, only the tagblib and config stuff?
> >
> > I think this is the way to go for now. I know, then the developer has to
> > ensure that the types of the setter on the UIComponent do not differ to
> > the property.
> > Another short term solution could be to just create an abstract basis
> > class with the setter/getter stuff but leave the real logic of the
> > component out of it. The developer then has to inherit from this class
> > the real component.
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: myfaces-faces-plugin - architecture
Posted by Matthias Wessendorf <ma...@apache.org>.
On Jan 30, 2008 1:59 PM, Martin Marinschek <ma...@gmail.com> wrote:
> Hi Mario,
>
> your second suggestion sounds viable for me - not for the API
> components, as those cannot change their inheritance, but for the
> tomahawk and MyFaces impl components, this should be doable (and a
> very good idea) indeed.
>
> @why Trinidad doesn't work with annotations: how would you then
> generate restoreState and saveState? And the getters? You don't want
> to write all the getters by hand, do you?
>
tobago is using @nnotations for generation (of config)
don't know 100%
> regards,
>
> Martin
>
>
> On 1/30/08, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi Matthias,
> > > yep.
> > > -xml configuration == "mini faces-config files"
> > > -templates == in order to "override" some *defaults* (like when you
> > > want to do something "special" inside the validate() for InputFile,
> > > provide a template, which is a real Java class)
> > > -it generates the real UIComponent java file as well
> > > -generates facelets XML taglib file
> > >
> > Is it possible to use the plugin in a way where the component/renderer
> > gets not generated, only the tagblib and config stuff?
> >
> > I think this is the way to go for now. I know, then the developer has to
> > ensure that the types of the setter on the UIComponent do not differ to
> > the property.
> > Another short term solution could be to just create an abstract basis
> > class with the setter/getter stuff but leave the real logic of the
> > component out of it. The developer then has to inherit from this class
> > the real component.
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: myfaces-faces-plugin - architecture
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Mario,
your second suggestion sounds viable for me - not for the API
components, as those cannot change their inheritance, but for the
tomahawk and MyFaces impl components, this should be doable (and a
very good idea) indeed.
@why Trinidad doesn't work with annotations: how would you then
generate restoreState and saveState? And the getters? You don't want
to write all the getters by hand, do you?
regards,
Martin
On 1/30/08, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Matthias,
> > yep.
> > -xml configuration == "mini faces-config files"
> > -templates == in order to "override" some *defaults* (like when you
> > want to do something "special" inside the validate() for InputFile,
> > provide a template, which is a real Java class)
> > -it generates the real UIComponent java file as well
> > -generates facelets XML taglib file
> >
> Is it possible to use the plugin in a way where the component/renderer
> gets not generated, only the tagblib and config stuff?
>
> I think this is the way to go for now. I know, then the developer has to
> ensure that the types of the setter on the UIComponent do not differ to
> the property.
> Another short term solution could be to just create an abstract basis
> class with the setter/getter stuff but leave the real logic of the
> component out of it. The developer then has to inherit from this class
> the real component.
>
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: myfaces-faces-plugin - architecture
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Matthias,
> yep.
> -xml configuration == "mini faces-config files"
> -templates == in order to "override" some *defaults* (like when you
> want to do something "special" inside the validate() for InputFile,
> provide a template, which is a real Java class)
> -it generates the real UIComponent java file as well
> -generates facelets XML taglib file
>
Is it possible to use the plugin in a way where the component/renderer
gets not generated, only the tagblib and config stuff?
I think this is the way to go for now. I know, then the developer has to
ensure that the types of the setter on the UIComponent do not differ to
the property.
Another short term solution could be to just create an abstract basis
class with the setter/getter stuff but leave the real logic of the
component out of it. The developer then has to inherit from this class
the real component.
Ciao,
Mario
Re: myfaces-faces-plugin - architecture
Posted by Matthias Wessendorf <ma...@apache.org>.
On Jan 30, 2008 1:39 PM, Simon Kitching <si...@chello.at> wrote:
> Hi,
>
> Are there any emails/design-docs available on why the trinidad build system (now myfaces-faces-plugin) was designed as it was?
don't think so;
it started as an ant-task, became a maven1 plugin; and now it is a
maven2 plguin.
>
> Currently, it uses xml configuration files plus java "template" files to generate java classes for components. It also then generates java source for jsp taglib handlers, and config files like .tld and faces-config.xml.
yep.
-xml configuration == "mini faces-config files"
-templates == in order to "override" some *defaults* (like when you
want to do something "special" inside the validate() for InputFile,
provide a template, which is a real Java class)
-it generates the real UIComponent java file as well
-generates facelets XML taglib file
>
> Was consideration given to instead driving the process from annotations (or xdoclet tags) attached to component, converter and validator classes? It would seem to me that this would be more natural for java developers to use...
don't know about the "historic" reasons.
-Matthias
>
> Thanks, Simon
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org