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
On Jan 30, 2008 1:39 PM, Simon Kitching [EMAIL PROTECTED] 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
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
On Jan 30, 2008 1:59 PM, Martin Marinschek [EMAIL PROTECTED] 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)
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
Hi,
On Jan 30, 2008 1:53 PM, Mario Ivankovits [EMAIL PROTECTED] 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,
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
Martin Marinschek [EMAIL PROTECTED] schrieb:
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.
I'm not quite sure what is
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
So, while I'd really support your idea about a annotation driven
generator, I don't think that we will
Hi all,
Mario Ivankovits napsal(a):
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
I was probably last to play with old generator (in Tomahawk
Mario Ivankovits [EMAIL PROTECTED] schrieb:
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
Only two attempts have been made. And the fact
These are my thoughts and my personal opinions on the subject
myfaces-faces-plugin generates 4 things:
component classes
tag classes
faces-config.xml
tld
Synchronize the generation of all this stuff with annotations is very
hard!. For each component we need one file. If this file is an
abstract
On Jan 30, 2008 8:03 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
These are my thoughts and my personal opinions on the subject
myfaces-faces-plugin generates 4 things:
component classes
tag classes
faces-config.xml
tld
and facelets taglib
Synchronize the generation of all this stuff
Leonardo Uribe schrieb:
For sure, I thought we can generate the stuff and then commit the
generated files, so no need to regenerate for each build, just when
something in the component config changed.
Yep, this just works nicely if we go the abstract component route, no?
else you'll lose all
To summarize:
The objective is to look if we can generate component, tag,
faces-config and facelets files using
a better approach than the actual behavior of myfaces-faces plugin.
The full idea could be this:
- Create an abstract component class that contains all info.
- Create some files
Don't forget that components are just one of the items generated. It is not
wise to make any architectural changes w/o considering all of the artifacts
the plug-in generates.
On Jan 30, 2008 12:34 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
To summarize:
The objective is to look if we can
Hi Leonardo,
I am of a contrary opinion to Matthias on the checkin issue - if it
helps the developer, the generated source-code can and should be
checked in. However, it is necessary that the files are re-generated
on every build (so we do not get out of sync between file and
configuration).
I
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
regards,
Martin
Hi,
On Jan 30, 2008 8:46 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Leonardo,
I am of a contrary opinion to Matthias on the checkin issue - if it
helps the developer, the generated source-code can and should be
checked in. However, it is necessary that the files are re-generated
on
Hi!
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I personally think we can go with option 1 only - there are not so
many API classes, and changes in the API are not ocurring too often.
+1
I have no problems if this does not work with the API
On Jan 30, 2008 8:48 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
the XML is nice.
It is used to generate the stupid compoents and it transforms the
faces-config,
with tons of
On Jan 30, 2008 2:48 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
IMO an annotation that covers all that information makes the class
much much more
un-readable.
XML is not that
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I personally think we can go with option 1 only - there are not so
many API classes, and changes in the API are not ocurring too often.
I have tested it in some cases in tomahawk, and works good.
I am with Matthias as whether to checkin in generated files or not. My
personal experience tells that adding generated files under subversion
makes the project more difficult to maintain, because you have to be
even more aware of how the code generation works. For instance, you
have to remove
-1 for a dummy abstract parent class. The resultant OO structure is not
clean. I would rather see a cleaner way to merge the template with the
generated code.
On Jan 30, 2008 1:04 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
1) we do an abstract component base class, very clean, however, it
And one thing about templates, you only need to deal with exceptions,
right? Most of the components don't need them,
Cheers,
Bruno
On 30/01/2008, Leonardo Uribe [EMAIL PROTECTED] wrote:
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I
On Jan 30, 2008 9:06 PM, Bruno Aranda [EMAIL PROTECTED] wrote:
I am with Matthias as whether to checkin in generated files or not. My
personal experience tells that adding generated files under subversion
makes the project more difficult to maintain, because you have to be
even more aware of
Hi Andrew,
On 1/30/08, Andrew Robinson [EMAIL PROTECTED] wrote:
-1 for a dummy abstract parent class. The resultant OO structure is not
clean. I would rather see a cleaner way to merge the template with the
generated code.
ok - then please suggest one. This is all about finding a clean way,
Hi!
ok - then please suggest one. This is all about finding a clean way,
and we are at this point as we haven't found another clean way to do
it so far.
I had a quick chat about this topic with Matthias and I think now I
understood a little bit better what the thought how to work with the
To make more clear this point about when we should add additional code on
component class, I will take some examples from my experience using
myfaces-faces-plugin for tomahawk. There is some situations where you have
to add custom code like this:
This is the code of
Leonardo Uribe schrieb:
Not have code completion and other features on the IDE is a low price
for we have with templates.
Not that I would like to veto at this point (which I am not able to do,
for sure), but:
We already gave up some comfort with having the shared stuff. You know,
you can
Trinidad view about how to develop components is that if we have some code
that could be in renderer we have to put in the renderer. But the practice
says that there are some situations when we need to write custom code on
component class.
you can override things, by providing a template,
Hey Mario,
On Jan 30, 2008 10:33 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Leonardo Uribe schrieb:
Not have code completion and other features on the IDE is a low price
for we have with templates.
Not that I would like to veto at this point (which I am not able to do,
for sure), but:
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to customize the broadcast method of this
component.
One alternative (my choice), as already mentioned is to have the plugin add
code to the class. Instead of using something like:
/* START
On Wed, 2008-01-30 at 16:11 -0500, Leonardo Uribe wrote:
One useful example of why templates are better than abstract classes
is this:
This is the code of
src/main/java-templates/org/apache/myfaces/custom/buffer/BufferTemplate.java
public class Buffer extends UIComponentBase{
{
Hi Simon,
I thnk that so far we all agree that:
* the old approach of files with ==do not edit this bit== sucks. It is
inelegant and people *do* edit that bit.
* having artificial generated parent classes sucks; it distorts the true
hierarchy and simply cannot be applied to the API classes.
FYI, to parse java source, it looks like there are many utils:
http://java-source.net/open-source/parser-generators
On Jan 30, 2008 3:41 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to
Hi Andrew,
On Wed, Jan 30, 2008 at 11:41 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to customize the broadcast method of this
component.
One alternative (my choice), as already
Here is another:
http://ws.apache.org/jaxme/js/jparser.html
I think you get the drift...
On Jan 30, 2008 4:00 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
FYI, to parse java source, it looks like there are many utils:
http://java-source.net/open-source/parser-generators
On Jan 30, 2008
Hi Leonardo,
If you want forceId feature works, you need to override getClientId(),and
if you want to use visibleOnUserRole property, you need to override
isRendered(). And also if you want that the component implements some
interfaces you need to specify this on the template.
In this
Ok, I understand.
* generating source into the src/main/java tree sucks, because it is
hard to tell generated code apart from non-generated stuff.
* generating source into the target tree sucks a bit, because you need
to explicitly add it to an IDE
So we agree that the option that sucks less is
Hi Leonardo,
* generating source into the src/main/java tree sucks, because it is
hard to tell generated code apart from non-generated stuff.
* generating source into the target tree sucks a bit, because you need
to explicitly add it to an IDE
So we agree that the option that sucks less is
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're using because I've never had problems with the
maven-faces-plugin generating source in the target tree. mvn
eclipse:eclipse or mvn idea:idea configures the project properly at
least for me as I don't
Hello,
On 01/31/2008 +0100,
Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Bernhard,
On Thu, Jan 31, 2008 at 12:54 AM, Bernhard Huemer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're
The only direct alternative I can see is Matthias' view that components
should not be edited at all, and all custom logic should be in renderer
classes. However like Mario I am rather skeptical about that; it just
does not sound right to me. And in any case, that still qualifies for a
The only direct alternative I can see is Matthias' view that components
should not be edited at all, and all custom logic should be in renderer
classes. However like Mario I am rather skeptical about that; it just
does not sound right to me. And in any case, that still qualifies for a
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're using because I've never had problems with the
maven-faces-plugin generating source in the target tree. mvn
eclipse:eclipse or mvn idea:idea configures the project properly at
least for me as I don't
Hi Matthias,
Matthias view sucks, cause component logic should be right where the
data
is, according to object-oriented principles - and not in the renderer.
The
renderer is only there for RENDERING logic, as the name says.
Please show me the lines, where I said no component logic
no, but according to Mario, you said - put the logic which is necessary for
the component into the base-renderer. Sorry for the sucks in the above
sentence, I admit, it is a bit harsh, but it needed to be there cause it
occurred on each and every line before this...
I haven't said that.
On Jan 31, 2008 6:45 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
The only direct alternative I can see is Matthias' view that components
should not be edited at all, and all custom logic should be in renderer
classes. However like Mario I am rather skeptical about that; it just
On Thu, 2008-01-31 at 06:45 +0100, Matthias Wessendorf wrote:
The only direct alternative I can see is Matthias' view that components
should not be edited at all, and all custom logic should be in renderer
classes. However like Mario I am rather skeptical about that; it just
does not
Hi Bernhard,
and what about the component-templates - can you debug the source for
them like this?
Why not? It's just another source folder. Usually IDEs don't mind
whether a source folder is located in a directory called target. ;-)
However, maybe I didn't get your question ..
ok - so
On Jan 30, 2008 9:39 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
ok - then please suggest one. This is all about finding a clean way,
and we are at this point as we haven't found another clean way to do
it so far.
I had a quick chat about this topic with Matthias and I think now I
Hi Leonardo
This is the code of
src/main/java-templates/org/apache/myfaces/custom/buffer/BufferTemplate.java
public class Buffer extends UIComponentBase{
{
/**/private String _into = null;
void fill(String content, FacesContext facesContext){
ValueExpression
Sorry, looks like we have all misunderstood what you meant.
not hard to misunderstood things in this threat
So you also recommend that a uicomponent should contain any business
logic specific to that component, and that the renderer just contain
the presentation logic? But in that case,
one more statement... perhaps the business logic term is/was confusing;
I create components/renderers all the day. My main job is writing the
RENDERER logic (for the renderer).
(client-side (JS) and server-side (java))
Since MY business is to fulfill the UI-spec, to make the components
look like
Hi Matthias,
you would not only have to recompile the api, but do a mvn build of the api
- is it half a minute? a minute? two? Why waste this time if we can help it?
But my main point here was to show that there is logic
in the Trinidad components, which (reading through this thread)
not
sorry again for that sucks - as i said, I only said it cause it needed to
fit with the rest of the sucky lines ;) I know perfectly well that Trinidad
cleanly separates component and renderer-logic. As I said, Mario and me just
want to make it easier for the component developer.
I am with you,
A suggestion was made earlier in this thread to put this stuff up on a wiki
page. I think that's a fine idea, and volunteer to do that tonight (ie in about
12 hours time) unless someone wants to do it first.
There have been some very good ideas and points made in this thread, but it is
now
thank you very much.
I am on the road tonight. = Fasching ;)
On Jan 31, 2008 8:26 AM, Simon Kitching [EMAIL PROTECTED] wrote:
A suggestion was made earlier in this thread to put this stuff up on a wiki
page. I think that's a fine idea, and volunteer to do that tonight (ie in
about 12 hours
60 matches
Mail list logo
