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/10/08 14:54:03 UTC

MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

That sounds really interesting. As you may know, we are working quite
actively in the implementation of MyFaces 1.2. Now I am migrating the
JSF core tags, but we will reach soon the point to migrate the HTML
Basic components. I don't know the exact details of how this
autogeneration works for Trinidad, but couldn't we have the same or
similar method to generate the JSF basic html components for MyFaces?

Sorry for cross-posting but I think this can be interesting,

Cheers,

Bruno

Re: Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Adam Winer <aw...@gmail.com>.
Errors come from configuring in two places instead of one.
There is no reason why annotations are necessarily better
than XML, especially when they become very complex
and refer to things that aren't even in the file being
annotated.

-- Adam


On 10/13/06, Alexandr Smirnov <as...@exadel.com> wrote:
> My dream is avoid to use any configuration files at all, since with
> external configuration file component class must be syncronized with it,
> this situation provide unnessesary work and can be source for errors. My
> idea same as simplified code development for EJB2, jboss Seam etc.
> Currently, for abstract bean property getter/setter pair i have right
> auto-generated JSF attribute ( but without any documentation,
> unfortunately ), for Event Listener Handler interface - component code,
> listener helper and tags.  I'm very 'lazy' developer, and alvais avoid
> to make work by hand if it can be done automatically.
> With little additional meta-information ( i seem java annotations as
> best way for provide it ) using of external configuration file is not need.
>
> Adam Winer :
> > Alexandr,
> >
> > What's wrong with faces-config.xml metadata?  From our
> > perspective, this has been a very successful source
> > of the information needed to derive things as diverse
> > as Javadoc, code, and TLDs (and, faces-config.xml
> > itself).
> >
> > The "XML is bad, annotations are great" line you here a lot these
> > days is waaaay overblown.  XML has its strengths, annotations
> > has its strengths.
> >
> > -- Adam
> >
> >
> > On 10/11/06, Alexandr Smirnov <as...@exadel.com> wrote:
> >> Component code generation can greatly improve components creation, since
> >> in Ajax4jsf project I also have own generator with same ideas. In
> >> addition to same files as in ADF/Trinidad , we have generator for
> >> renderer's from jsp-like template ( even with same tags as Jsp/jstl,
> >> which allow to use JSP visual editor for renderer's ). For complex
> >> components  , it allow avoid most of html errors and can divide work
> >> between html designer and java coders.
> >> As a next stage, I want to reduce files need for component creation to
> >> two - base abstract component class, and renderer template. For
> >> component meta information, I have plan to use Java annotations ( in
> >> current implementation, I use Java reflection to analise component and
> >> implemented interfaces methods, bean properties etc. ). As I thing, such
> >> annotations must be standardize, not proprietary API. Is
> >> Myfaces/Trinidad team will interested to use annotations for component
> >> generator meta information ? I need help to create public api for such
> >> feature.
> >> Also, we can contribute parts of existing generator to MyFaces project,
> >> at least renderer generator part - I don't see such feature in other
> >> tools.
> >>
> >> Adam Winer :
> >> > Yes, they definitely could be used in that way.
> >> >
> >> > The basic picture is that you write up a bunch of little mini
> >> > faces-config.xml files, one for each component (don't have to,
> >> > actually, you could generate straight from one big faces-config),
> >> > and from that we autogenerate:
> >> > - Java component classes
> >> > - JSP tag classes
> >> > - TLD file
> >> > - Tag documentation
> >> > - Facelets definition file
> >> > - Overall merged faces-config.xml
> >> >
> >> > -- Adam
> >> >
> >> >
> >> > On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> >> >> That sounds really interesting. As you may know, we are working quite
> >> >> actively in the implementation of MyFaces 1.2. Now I am migrating the
> >> >> JSF core tags, but we will reach soon the point to migrate the HTML
> >> >> Basic components. I don't know the exact details of how this
> >> >> autogeneration works for Trinidad, but couldn't we have the same or
> >> >> similar method to generate the JSF basic html components for MyFaces?
> >> >>
> >> >> Sorry for cross-posting but I think this can be interesting,
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Bruno
> >> >>
> >>
> >>
>
>

Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Alexandr Smirnov <as...@exadel.com>.
My dream is avoid to use any configuration files at all, since with 
external configuration file component class must be syncronized with it, 
this situation provide unnessesary work and can be source for errors. My 
idea same as simplified code development for EJB2, jboss Seam etc.
Currently, for abstract bean property getter/setter pair i have right 
auto-generated JSF attribute ( but without any documentation, 
unfortunately ), for Event Listener Handler interface - component code, 
listener helper and tags.  I'm very 'lazy' developer, and alvais avoid 
to make work by hand if it can be done automatically.
With little additional meta-information ( i seem java annotations as 
best way for provide it ) using of external configuration file is not need.

Adam Winer :
> Alexandr,
>
> What's wrong with faces-config.xml metadata?  From our
> perspective, this has been a very successful source
> of the information needed to derive things as diverse
> as Javadoc, code, and TLDs (and, faces-config.xml
> itself).
>
> The "XML is bad, annotations are great" line you here a lot these
> days is waaaay overblown.  XML has its strengths, annotations
> has its strengths.
>
> -- Adam
>
>
> On 10/11/06, Alexandr Smirnov <as...@exadel.com> wrote:
>> Component code generation can greatly improve components creation, since
>> in Ajax4jsf project I also have own generator with same ideas. In
>> addition to same files as in ADF/Trinidad , we have generator for
>> renderer's from jsp-like template ( even with same tags as Jsp/jstl,
>> which allow to use JSP visual editor for renderer's ). For complex
>> components  , it allow avoid most of html errors and can divide work
>> between html designer and java coders.
>> As a next stage, I want to reduce files need for component creation to
>> two - base abstract component class, and renderer template. For
>> component meta information, I have plan to use Java annotations ( in
>> current implementation, I use Java reflection to analise component and
>> implemented interfaces methods, bean properties etc. ). As I thing, such
>> annotations must be standardize, not proprietary API. Is
>> Myfaces/Trinidad team will interested to use annotations for component
>> generator meta information ? I need help to create public api for such
>> feature.
>> Also, we can contribute parts of existing generator to MyFaces project,
>> at least renderer generator part - I don't see such feature in other 
>> tools.
>>
>> Adam Winer :
>> > Yes, they definitely could be used in that way.
>> >
>> > The basic picture is that you write up a bunch of little mini
>> > faces-config.xml files, one for each component (don't have to,
>> > actually, you could generate straight from one big faces-config),
>> > and from that we autogenerate:
>> > - Java component classes
>> > - JSP tag classes
>> > - TLD file
>> > - Tag documentation
>> > - Facelets definition file
>> > - Overall merged faces-config.xml
>> >
>> > -- Adam
>> >
>> >
>> > On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
>> >> That sounds really interesting. As you may know, we are working quite
>> >> actively in the implementation of MyFaces 1.2. Now I am migrating the
>> >> JSF core tags, but we will reach soon the point to migrate the HTML
>> >> Basic components. I don't know the exact details of how this
>> >> autogeneration works for Trinidad, but couldn't we have the same or
>> >> similar method to generate the JSF basic html components for MyFaces?
>> >>
>> >> Sorry for cross-posting but I think this can be interesting,
>> >>
>> >> Cheers,
>> >>
>> >> Bruno
>> >>
>>
>>


Re: Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Adam Winer <aw...@gmail.com>.
Alexandr,

What's wrong with faces-config.xml metadata?  From our
perspective, this has been a very successful source
of the information needed to derive things as diverse
as Javadoc, code, and TLDs (and, faces-config.xml
itself).

The "XML is bad, annotations are great" line you here a lot these
days is waaaay overblown.  XML has its strengths, annotations
has its strengths.

-- Adam


On 10/11/06, Alexandr Smirnov <as...@exadel.com> wrote:
> Component code generation can greatly improve components creation, since
> in Ajax4jsf project I also have own generator with same ideas. In
> addition to same files as in ADF/Trinidad , we have generator for
> renderer's from jsp-like template ( even with same tags as Jsp/jstl,
> which allow to use JSP visual editor for renderer's ). For complex
> components  , it allow avoid most of html errors and can divide work
> between html designer and java coders.
> As a next stage, I want to reduce files need for component creation to
> two - base abstract component class, and renderer template. For
> component meta information, I have plan to use Java annotations ( in
> current implementation, I use Java reflection to analise component and
> implemented interfaces methods, bean properties etc. ). As I thing, such
> annotations must be standardize, not proprietary API. Is
> Myfaces/Trinidad team will interested to use annotations for component
> generator meta information ? I need help to create public api for such
> feature.
> Also, we can contribute parts of existing generator to MyFaces project,
> at least renderer generator part - I don't see such feature in other tools.
>
> Adam Winer :
> > Yes, they definitely could be used in that way.
> >
> > The basic picture is that you write up a bunch of little mini
> > faces-config.xml files, one for each component (don't have to,
> > actually, you could generate straight from one big faces-config),
> > and from that we autogenerate:
> > - Java component classes
> > - JSP tag classes
> > - TLD file
> > - Tag documentation
> > - Facelets definition file
> > - Overall merged faces-config.xml
> >
> > -- Adam
> >
> >
> > On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> >> That sounds really interesting. As you may know, we are working quite
> >> actively in the implementation of MyFaces 1.2. Now I am migrating the
> >> JSF core tags, but we will reach soon the point to migrate the HTML
> >> Basic components. I don't know the exact details of how this
> >> autogeneration works for Trinidad, but couldn't we have the same or
> >> similar method to generate the JSF basic html components for MyFaces?
> >>
> >> Sorry for cross-posting but I think this can be interesting,
> >>
> >> Cheers,
> >>
> >> Bruno
> >>
>
>

Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Alexandr Smirnov <as...@exadel.com>.
Component code generation can greatly improve components creation, since 
in Ajax4jsf project I also have own generator with same ideas. In 
addition to same files as in ADF/Trinidad , we have generator for 
renderer's from jsp-like template ( even with same tags as Jsp/jstl, 
which allow to use JSP visual editor for renderer's ). For complex 
components  , it allow avoid most of html errors and can divide work 
between html designer and java coders.
As a next stage, I want to reduce files need for component creation to 
two - base abstract component class, and renderer template. For 
component meta information, I have plan to use Java annotations ( in 
current implementation, I use Java reflection to analise component and 
implemented interfaces methods, bean properties etc. ). As I thing, such 
annotations must be standardize, not proprietary API. Is 
Myfaces/Trinidad team will interested to use annotations for component 
generator meta information ? I need help to create public api for such 
feature.
Also, we can contribute parts of existing generator to MyFaces project, 
at least renderer generator part - I don't see such feature in other tools.

Adam Winer :
> Yes, they definitely could be used in that way.
>
> The basic picture is that you write up a bunch of little mini
> faces-config.xml files, one for each component (don't have to,
> actually, you could generate straight from one big faces-config),
> and from that we autogenerate:
> - Java component classes
> - JSP tag classes
> - TLD file
> - Tag documentation
> - Facelets definition file
> - Overall merged faces-config.xml
>
> -- Adam
>
>
> On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
>> That sounds really interesting. As you may know, we are working quite
>> actively in the implementation of MyFaces 1.2. Now I am migrating the
>> JSF core tags, but we will reach soon the point to migrate the HTML
>> Basic components. I don't know the exact details of how this
>> autogeneration works for Trinidad, but couldn't we have the same or
>> similar method to generate the JSF basic html components for MyFaces?
>>
>> Sorry for cross-posting but I think this can be interesting,
>>
>> Cheers,
>>
>> Bruno
>>


Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Adam Winer <aw...@gmail.com>.
Yes, they definitely could be used in that way.

The basic picture is that you write up a bunch of little mini
faces-config.xml files, one for each component (don't have to,
actually, you could generate straight from one big faces-config),
and from that we autogenerate:
 - Java component classes
 - JSP tag classes
 - TLD file
 - Tag documentation
 - Facelets definition file
 - Overall merged faces-config.xml

-- Adam


On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> That sounds really interesting. As you may know, we are working quite
> actively in the implementation of MyFaces 1.2. Now I am migrating the
> JSF core tags, but we will reach soon the point to migrate the HTML
> Basic components. I don't know the exact details of how this
> autogeneration works for Trinidad, but couldn't we have the same or
> similar method to generate the JSF basic html components for MyFaces?
>
> Sorry for cross-posting but I think this can be interesting,
>
> Cheers,
>
> Bruno
>

Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Adam Winer <aw...@gmail.com>.
Yes, they definitely could be used in that way.

The basic picture is that you write up a bunch of little mini
faces-config.xml files, one for each component (don't have to,
actually, you could generate straight from one big faces-config),
and from that we autogenerate:
 - Java component classes
 - JSP tag classes
 - TLD file
 - Tag documentation
 - Facelets definition file
 - Overall merged faces-config.xml

-- Adam


On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> That sounds really interesting. As you may know, we are working quite
> actively in the implementation of MyFaces 1.2. Now I am migrating the
> JSF core tags, but we will reach soon the point to migrate the HTML
> Basic components. I don't know the exact details of how this
> autogeneration works for Trinidad, but couldn't we have the same or
> similar method to generate the JSF basic html components for MyFaces?
>
> Sorry for cross-posting but I think this can be interesting,
>
> Cheers,
>
> Bruno
>

Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Bruno Aranda <br...@gmail.com>.
Uhm, I forgot to add the mail I was refering to, by Adam Winer:

<< Adam:
Hey, BTW, what happens with java-templates:  we
autogenerate almost all our component (and a number of
other) .java files.  However, when there needs to
be some non-auto-generated, manual code, we put
that in java-templates.  So UIXCommandTemplate.java
automatically gets merged into the generated UIXCommand.java
file.

One of the cool things about the technique Trinidad uses
is that UIXCommandTemplate.java is actually a fully
valid .java file - so you can add it to an IDE and
compile it, etc., to make sure it's valid.  But it's
ignored at runtime, and not in our JAR - only the
merged UIXCommand is.
>>

On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> That sounds really interesting. As you may know, we are working quite
> actively in the implementation of MyFaces 1.2. Now I am migrating the
> JSF core tags, but we will reach soon the point to migrate the HTML
> Basic components. I don't know the exact details of how this
> autogeneration works for Trinidad, but couldn't we have the same or
> similar method to generate the JSF basic html components for MyFaces?
>
> Sorry for cross-posting but I think this can be interesting,
>
> Cheers,
>
> Bruno
>

Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)

Posted by Bruno Aranda <br...@gmail.com>.
Uhm, I forgot to add the mail I was refering to, by Adam Winer:

<< Adam:
Hey, BTW, what happens with java-templates:  we
autogenerate almost all our component (and a number of
other) .java files.  However, when there needs to
be some non-auto-generated, manual code, we put
that in java-templates.  So UIXCommandTemplate.java
automatically gets merged into the generated UIXCommand.java
file.

One of the cool things about the technique Trinidad uses
is that UIXCommandTemplate.java is actually a fully
valid .java file - so you can add it to an IDE and
compile it, etc., to make sure it's valid.  But it's
ignored at runtime, and not in our JAR - only the
merged UIXCommand is.
>>

On 10/8/06, Bruno Aranda <br...@gmail.com> wrote:
> That sounds really interesting. As you may know, we are working quite
> actively in the implementation of MyFaces 1.2. Now I am migrating the
> JSF core tags, but we will reach soon the point to migrate the HTML
> Basic components. I don't know the exact details of how this
> autogeneration works for Trinidad, but couldn't we have the same or
> similar method to generate the JSF basic html components for MyFaces?
>
> Sorry for cross-posting but I think this can be interesting,
>
> Cheers,
>
> Bruno
>