You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Mathias Brökelmann <mb...@googlemail.com> on 2007/03/07 14:11:14 UTC
about maven-faces-plugin
Hi all,
During myfaces 1.2 development I came across the maven-faces-plugin from
trinidad. AFAIK it uses some xml files which contains the model for
the generated components. This saves a lot of time to quickly get new
components into work. But there is room to improve it.
Currently customizing the generated component classes requires to
write a template file (like UIViewRootTemplate.java) which contains
custom code. I don't like this approach. Since there is no chance to
modify generated methods and to add custom code. That is even worse if
you only want to add something to save/restore state methods or to add
some parameter checking for setters. I've already seen that some dirty
hacks are implemented to make things work - at least for using it in myfaces.
IMO there is a way to solve some of the problems by still having
generated code. I'm thinking of an "in place editing" the generated
code inside special marks like this:
public void setXXX(String xxx)
{
/* start custom code */
// do something before the generated code
/* end custom code */
_XXX = xxx;
/* start custom code */
// do something after the generated code
/* end custom code */
}
WDYT?
--
Mathias
Re: about maven-faces-plugin
Posted by Adam Winer <aw...@gmail.com>.
On 3/8/07, Martin Marinschek <ma...@gmail.com> wrote:
> I still wonder if the approach MyFaces originally had wasn't better
> than the new approach of the generator in Trinidad.
>
> Apart from the fact of course that generation should happen on every
> run of the build - we kind of neglected that.
>
> What you have with the Trinidad generator now is:
>
> ...Template.java:
>
> ...
>
> void myMethod() {
> setMyProperty(test); //won't compile, cause setMyProperty is autogenerated!
> }
The generator suports a special syntax:
/**/public abstract setMyProperty(...)
for just this sort of thing.
> with the MyFaces initial method, this was all in one file, with special markers:
>
> Component.java
>
> void myMethod(){
> setMyProperty(test); //compiles, cause in the same file
> }
>
> /** auto generated begin - don't change this code **/
>
> public void setProperty(String property) {...}
>
> /** auto generated end - don't change this code **/
But that means that you've checked into source control
auto-generated code. Which is a BIG problem.
Auto-generated code should be generated at build
time, and never get checked in.
-- Adam
Re: about maven-faces-plugin
Posted by Martin Marinschek <ma...@gmail.com>.
I still wonder if the approach MyFaces originally had wasn't better
than the new approach of the generator in Trinidad.
Apart from the fact of course that generation should happen on every
run of the build - we kind of neglected that.
What you have with the Trinidad generator now is:
...Template.java:
...
void myMethod() {
setMyProperty(test); //won't compile, cause setMyProperty is autogenerated!
}
with the MyFaces initial method, this was all in one file, with special markers:
Component.java
void myMethod(){
setMyProperty(test); //compiles, cause in the same file
}
/** auto generated begin - don't change this code **/
public void setProperty(String property) {...}
/** auto generated end - don't change this code **/
regards,
Martin
On 3/7/07, Adam Winer <aw...@gmail.com> wrote:
> On 3/7/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > what I didn't like this morning, for fixing a bug on MyFAces' JSF 1.2
> > UIViewRoot is,
> > that I need to put this statement:
> >
> > /**///getPhaseListeners
> >
> >
> > to get a *ignored* getter for the phaseListeners property.
>
> Well, you need this if you're going to try to compile
> the template, and you need to refer to a method that will
> be auto-generated from code that isn't auto-generated.
> If you're not compiling the template, that's not necessary.
>
> It's certainly not pretty - an annotation of some sort
> would be way better - but it has the distinct advantage
> of being a piece of logic that I could code in minutes.
> (The principle of "Good Enough" applies. :) )
>
> -- Adam
>
>
>
>
> >
> > The rest is fine, at least the part I was dealing w/ in order to get
> > some stuff working in Trinidad
> >
> > -M
> >
> > On 3/7/07, Adam Winer <aw...@gmail.com> wrote:
> > > In general, I think the approach used by the faces plugin
> > > is a really good thing. You want as much autogenerated
> > > as possible (this made upgrading to JSF 1.2 vastly easier
> > > than without it). And the specific approach actually
> > > allows for treating the template .java files as fully
> > > compileable sources - you can add them to your IDE
> > > and get full code insight, syntax checking, etc. Most
> > > systems I've seen for templated code don't offer that;
> > > the templated Java is pseudo-code that no IDE will
> > > accept.
> > >
> > > I agree with Bruno that the plugin could definitely
> > > be improved... some injection might be good,
> > > velocity templates for method generation would
> > > probably be waaaay easier than all the Java code, etc.
> > >
> > > -- Adam
> > >
> > >
> > > On 3/7/07, Bruno Aranda <br...@gmail.com> wrote:
> > > > IMO I prefer to use as much as I can the code autogenerated without
> > > > having to add new code to the methods (delegating all this to the code
> > > > generator). This eases the process of migrating code. Adding very
> > > > specific code to methods might break future migrations (e.g. migrating
> > > > tomahawk components to use trinidad state management), as the specific
> > > > code could no longer compile. Of course, this can be a minor thing so
> > > > I am open to this possibility of "injecting" code before/after the
> > > > method's logic, as aspects do. How would you do it, though?
> > > > And of course, there is a great space for improving in the plugin and
> > > > it would be wonderful at some point to have it based in velocity,
> > > >
> > > > Cheers,
> > > >
> > > > Bruno
> > > >
> > > > On 07/03/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > During myfaces 1.2 development I came across the maven-faces-plugin from
> > > > > trinidad. AFAIK it uses some xml files which contains the model for
> > > > > the generated components. This saves a lot of time to quickly get new
> > > > > components into work. But there is room to improve it.
> > > > >
> > > > > Currently customizing the generated component classes requires to
> > > > > write a template file (like UIViewRootTemplate.java) which contains
> > > > > custom code. I don't like this approach. Since there is no chance to
> > > > > modify generated methods and to add custom code. That is even worse if
> > > > > you only want to add something to save/restore state methods or to add
> > > > > some parameter checking for setters. I've already seen that some dirty
> > > > > hacks are implemented to make things work - at least for using it in myfaces.
> > > > >
> > > > > IMO there is a way to solve some of the problems by still having
> > > > > generated code. I'm thinking of an "in place editing" the generated
> > > > > code inside special marks like this:
> > > > >
> > > > > public void setXXX(String xxx)
> > > > > {
> > > > > /* start custom code */
> > > > > // do something before the generated code
> > > > > /* end custom code */
> > > > >
> > > > > _XXX = xxx;
> > > > >
> > > > > /* start custom code */
> > > > > // do something after the generated code
> > > > > /* end custom code */
> > > > > }
> > > > >
> > > > > WDYT?
> > > > >
> > > > > --
> > > > > Mathias
> > > > >
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: about maven-faces-plugin
Posted by Adam Winer <aw...@gmail.com>.
On 3/7/07, Matthias Wessendorf <ma...@apache.org> wrote:
> what I didn't like this morning, for fixing a bug on MyFAces' JSF 1.2
> UIViewRoot is,
> that I need to put this statement:
>
> /**///getPhaseListeners
>
>
> to get a *ignored* getter for the phaseListeners property.
Well, you need this if you're going to try to compile
the template, and you need to refer to a method that will
be auto-generated from code that isn't auto-generated.
If you're not compiling the template, that's not necessary.
It's certainly not pretty - an annotation of some sort
would be way better - but it has the distinct advantage
of being a piece of logic that I could code in minutes.
(The principle of "Good Enough" applies. :) )
-- Adam
>
> The rest is fine, at least the part I was dealing w/ in order to get
> some stuff working in Trinidad
>
> -M
>
> On 3/7/07, Adam Winer <aw...@gmail.com> wrote:
> > In general, I think the approach used by the faces plugin
> > is a really good thing. You want as much autogenerated
> > as possible (this made upgrading to JSF 1.2 vastly easier
> > than without it). And the specific approach actually
> > allows for treating the template .java files as fully
> > compileable sources - you can add them to your IDE
> > and get full code insight, syntax checking, etc. Most
> > systems I've seen for templated code don't offer that;
> > the templated Java is pseudo-code that no IDE will
> > accept.
> >
> > I agree with Bruno that the plugin could definitely
> > be improved... some injection might be good,
> > velocity templates for method generation would
> > probably be waaaay easier than all the Java code, etc.
> >
> > -- Adam
> >
> >
> > On 3/7/07, Bruno Aranda <br...@gmail.com> wrote:
> > > IMO I prefer to use as much as I can the code autogenerated without
> > > having to add new code to the methods (delegating all this to the code
> > > generator). This eases the process of migrating code. Adding very
> > > specific code to methods might break future migrations (e.g. migrating
> > > tomahawk components to use trinidad state management), as the specific
> > > code could no longer compile. Of course, this can be a minor thing so
> > > I am open to this possibility of "injecting" code before/after the
> > > method's logic, as aspects do. How would you do it, though?
> > > And of course, there is a great space for improving in the plugin and
> > > it would be wonderful at some point to have it based in velocity,
> > >
> > > Cheers,
> > >
> > > Bruno
> > >
> > > On 07/03/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > > Hi all,
> > > >
> > > > During myfaces 1.2 development I came across the maven-faces-plugin from
> > > > trinidad. AFAIK it uses some xml files which contains the model for
> > > > the generated components. This saves a lot of time to quickly get new
> > > > components into work. But there is room to improve it.
> > > >
> > > > Currently customizing the generated component classes requires to
> > > > write a template file (like UIViewRootTemplate.java) which contains
> > > > custom code. I don't like this approach. Since there is no chance to
> > > > modify generated methods and to add custom code. That is even worse if
> > > > you only want to add something to save/restore state methods or to add
> > > > some parameter checking for setters. I've already seen that some dirty
> > > > hacks are implemented to make things work - at least for using it in myfaces.
> > > >
> > > > IMO there is a way to solve some of the problems by still having
> > > > generated code. I'm thinking of an "in place editing" the generated
> > > > code inside special marks like this:
> > > >
> > > > public void setXXX(String xxx)
> > > > {
> > > > /* start custom code */
> > > > // do something before the generated code
> > > > /* end custom code */
> > > >
> > > > _XXX = xxx;
> > > >
> > > > /* start custom code */
> > > > // do something after the generated code
> > > > /* end custom code */
> > > > }
> > > >
> > > > WDYT?
> > > >
> > > > --
> > > > Mathias
> > > >
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: about maven-faces-plugin
Posted by Matthias Wessendorf <ma...@apache.org>.
what I didn't like this morning, for fixing a bug on MyFAces' JSF 1.2
UIViewRoot is,
that I need to put this statement:
/**///getPhaseListeners
to get a *ignored* getter for the phaseListeners property.
The rest is fine, at least the part I was dealing w/ in order to get
some stuff working in Trinidad
-M
On 3/7/07, Adam Winer <aw...@gmail.com> wrote:
> In general, I think the approach used by the faces plugin
> is a really good thing. You want as much autogenerated
> as possible (this made upgrading to JSF 1.2 vastly easier
> than without it). And the specific approach actually
> allows for treating the template .java files as fully
> compileable sources - you can add them to your IDE
> and get full code insight, syntax checking, etc. Most
> systems I've seen for templated code don't offer that;
> the templated Java is pseudo-code that no IDE will
> accept.
>
> I agree with Bruno that the plugin could definitely
> be improved... some injection might be good,
> velocity templates for method generation would
> probably be waaaay easier than all the Java code, etc.
>
> -- Adam
>
>
> On 3/7/07, Bruno Aranda <br...@gmail.com> wrote:
> > IMO I prefer to use as much as I can the code autogenerated without
> > having to add new code to the methods (delegating all this to the code
> > generator). This eases the process of migrating code. Adding very
> > specific code to methods might break future migrations (e.g. migrating
> > tomahawk components to use trinidad state management), as the specific
> > code could no longer compile. Of course, this can be a minor thing so
> > I am open to this possibility of "injecting" code before/after the
> > method's logic, as aspects do. How would you do it, though?
> > And of course, there is a great space for improving in the plugin and
> > it would be wonderful at some point to have it based in velocity,
> >
> > Cheers,
> >
> > Bruno
> >
> > On 07/03/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > Hi all,
> > >
> > > During myfaces 1.2 development I came across the maven-faces-plugin from
> > > trinidad. AFAIK it uses some xml files which contains the model for
> > > the generated components. This saves a lot of time to quickly get new
> > > components into work. But there is room to improve it.
> > >
> > > Currently customizing the generated component classes requires to
> > > write a template file (like UIViewRootTemplate.java) which contains
> > > custom code. I don't like this approach. Since there is no chance to
> > > modify generated methods and to add custom code. That is even worse if
> > > you only want to add something to save/restore state methods or to add
> > > some parameter checking for setters. I've already seen that some dirty
> > > hacks are implemented to make things work - at least for using it in myfaces.
> > >
> > > IMO there is a way to solve some of the problems by still having
> > > generated code. I'm thinking of an "in place editing" the generated
> > > code inside special marks like this:
> > >
> > > public void setXXX(String xxx)
> > > {
> > > /* start custom code */
> > > // do something before the generated code
> > > /* end custom code */
> > >
> > > _XXX = xxx;
> > >
> > > /* start custom code */
> > > // do something after the generated code
> > > /* end custom code */
> > > }
> > >
> > > WDYT?
> > >
> > > --
> > > Mathias
> > >
> >
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: about maven-faces-plugin
Posted by Adam Winer <aw...@gmail.com>.
In general, I think the approach used by the faces plugin
is a really good thing. You want as much autogenerated
as possible (this made upgrading to JSF 1.2 vastly easier
than without it). And the specific approach actually
allows for treating the template .java files as fully
compileable sources - you can add them to your IDE
and get full code insight, syntax checking, etc. Most
systems I've seen for templated code don't offer that;
the templated Java is pseudo-code that no IDE will
accept.
I agree with Bruno that the plugin could definitely
be improved... some injection might be good,
velocity templates for method generation would
probably be waaaay easier than all the Java code, etc.
-- Adam
On 3/7/07, Bruno Aranda <br...@gmail.com> wrote:
> IMO I prefer to use as much as I can the code autogenerated without
> having to add new code to the methods (delegating all this to the code
> generator). This eases the process of migrating code. Adding very
> specific code to methods might break future migrations (e.g. migrating
> tomahawk components to use trinidad state management), as the specific
> code could no longer compile. Of course, this can be a minor thing so
> I am open to this possibility of "injecting" code before/after the
> method's logic, as aspects do. How would you do it, though?
> And of course, there is a great space for improving in the plugin and
> it would be wonderful at some point to have it based in velocity,
>
> Cheers,
>
> Bruno
>
> On 07/03/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > Hi all,
> >
> > During myfaces 1.2 development I came across the maven-faces-plugin from
> > trinidad. AFAIK it uses some xml files which contains the model for
> > the generated components. This saves a lot of time to quickly get new
> > components into work. But there is room to improve it.
> >
> > Currently customizing the generated component classes requires to
> > write a template file (like UIViewRootTemplate.java) which contains
> > custom code. I don't like this approach. Since there is no chance to
> > modify generated methods and to add custom code. That is even worse if
> > you only want to add something to save/restore state methods or to add
> > some parameter checking for setters. I've already seen that some dirty
> > hacks are implemented to make things work - at least for using it in myfaces.
> >
> > IMO there is a way to solve some of the problems by still having
> > generated code. I'm thinking of an "in place editing" the generated
> > code inside special marks like this:
> >
> > public void setXXX(String xxx)
> > {
> > /* start custom code */
> > // do something before the generated code
> > /* end custom code */
> >
> > _XXX = xxx;
> >
> > /* start custom code */
> > // do something after the generated code
> > /* end custom code */
> > }
> >
> > WDYT?
> >
> > --
> > Mathias
> >
>
Re: about maven-faces-plugin
Posted by Bruno Aranda <br...@gmail.com>.
IMO I prefer to use as much as I can the code autogenerated without
having to add new code to the methods (delegating all this to the code
generator). This eases the process of migrating code. Adding very
specific code to methods might break future migrations (e.g. migrating
tomahawk components to use trinidad state management), as the specific
code could no longer compile. Of course, this can be a minor thing so
I am open to this possibility of "injecting" code before/after the
method's logic, as aspects do. How would you do it, though?
And of course, there is a great space for improving in the plugin and
it would be wonderful at some point to have it based in velocity,
Cheers,
Bruno
On 07/03/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> Hi all,
>
> During myfaces 1.2 development I came across the maven-faces-plugin from
> trinidad. AFAIK it uses some xml files which contains the model for
> the generated components. This saves a lot of time to quickly get new
> components into work. But there is room to improve it.
>
> Currently customizing the generated component classes requires to
> write a template file (like UIViewRootTemplate.java) which contains
> custom code. I don't like this approach. Since there is no chance to
> modify generated methods and to add custom code. That is even worse if
> you only want to add something to save/restore state methods or to add
> some parameter checking for setters. I've already seen that some dirty
> hacks are implemented to make things work - at least for using it in myfaces.
>
> IMO there is a way to solve some of the problems by still having
> generated code. I'm thinking of an "in place editing" the generated
> code inside special marks like this:
>
> public void setXXX(String xxx)
> {
> /* start custom code */
> // do something before the generated code
> /* end custom code */
>
> _XXX = xxx;
>
> /* start custom code */
> // do something after the generated code
> /* end custom code */
> }
>
> WDYT?
>
> --
> Mathias
>