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 <[EMAIL PROTECTED]> wrote:
On 3/7/07, Matthias Wessendorf <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
