Sorry for jumping that late into the thread since I am facing similar
issues currently I started to read it.
Leonardo Uribe schrieb:
Hi
I have made a wiki page for MyfaceBuilderPlugin here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
There is written the ideas present on the sample
+1 for templating, whether it is velocity or freemarker(my vote is on
freemarker btw:), it's a much better solution than using printwriter api.
Much easier to test and maintain.
C.C.
On Fri, Mar 28, 2008 at 2:07 PM, Werner Punz [EMAIL PROTECTED] wrote:
Sorry for jumping that late into the
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas or dtds. Is
something similar available for javadoc annotations in the standard
Hi Mike,
Although the metadata is written like a javadoc comment, it is not
processed by the javadoc tool. The qdox (qdox.codehaus.org) library is a
full java parser that builds a datastructure representing everything in
the java files you feed it - except the method bodies. This includes
Ok, so to summarize, validation would only happen during the maven
build process.
I did a quick search for QDox plugins (Eclipse, Idea, Netbeans) and
didn't immediately find anything.
On 3/21/08, simon [EMAIL PROTECTED] wrote:
Hi Mike,
Although the metadata is written like a javadoc comment,
Leonardo Uribe schrieb:
On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
[1] I'm not sure what the later property examples on that page are meant
to be; as Leonardo has written them they are attached to no function
Hi, is this possible with the myfaces-builder-plugin to extend components
that are part of another jar library (e.g. extending a tomahawk component
from a third-party lib)?.
Cheers!
Bruno
On 19/03/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Leonardo Uribe schrieb:
On Tue, Mar 18, 2008
Hi Bruno,
The plugin goals for config-file and code generation requires a
myfaces-metadata.xml file as input which contains all the info about
component classes, properties, etc.
For the case where tomahawk extends myfaces-api and myfaces-impl, that
file is just available directly from the jar's
On Wed, Mar 19, 2008 at 3:39 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Leonardo Uribe schrieb:
Thanks Simon for make more clear this on the wiki page. I have
also
added comments about how
should work isSetFieldMethod and isGetLocalMethod attributes for
Leonardo Uribe schrieb:
On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Is this supposed to be a solution to the code replacement? I don't
recall any vote to achieve a resolution on how to go about
Hi, I like the approach. I am not very keen in annotated javadocs (which
is error prone IMO) but that is just fine and I would say a better
alternative to the XMLs (which are rather error prone too). However, it
would be nice to have the builder library generic enough so we could use
javadocs now
Hi!
Hi, I like the approach. I am not very keen in annotated javadocs
(which is error prone IMO) but that is just fine and I would say a
better alternative to the XMLs (which are rather error prone too).
However, it would be nice to have the builder library generic enough
so we could use
Hi all,
comments inline.
[EMAIL PROTECTED] napsal(a):
The myfaces-builder-plugin stuff is an experiment/proof-of-concept at
the current time, That's why the code is in a branches directory. No
vote has been taken on using this approach; it was necessary to show
that this would work before
Hi Zdenek,
you seem to ignore my comments - you will need to provide the setters,
this is in the spec - and there is component-binding, so you need to
provide them?
The issue with state-saving will need to be saved another way.
regards,
Martin
On 3/18/08, Sochor Zdeněk [EMAIL PROTECTED]
Hi Zdenek,
*saved=solved
regards,
Martin
On 3/18/08, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Zdenek,
you seem to ignore my comments - you will need to provide the setters,
this is in the spec - and there is component-binding, so you need to
provide them?
The issue with
Hi Martin,
Martin Marinschek napsal(a):
Hi Zdenek,
*saved=solved
regards,
Martin
On 3/18/08, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Zdenek,
you seem to ignore my comments - you will need to provide the setters,
this is in the spec - and there is component-binding, so you need to
Sochor Zdeněk schrieb:
Generally extending components by adding whole bucket of local
property/getter/setter seems not right for me because
it's meant to provide just another feature not used by many people.
Wouldn't it be more cleaner to just use that property as attribute (in
JSF api's
One major drawback to the javadoc annotation approach has been left
out and that is attribute reuse. The maven-faces-plugin allows you to
import XML fragments using XPath. So in Trinidad, onclick,
onmouseover, onmouseout, etc. you can import one XML file and not have
to re-define all these. But
Hi,
[EMAIL PROTECTED] napsal(a):
Sochor Zdeněk schrieb:
Generally extending components by adding whole bucket of local
property/getter/setter seems not right for me because
it's meant to provide just another feature not used by many people.
Wouldn't it be more cleaner to just use that
Hi Andrew,
Andrew Robinson schrieb:
One major drawback to the javadoc annotation approach has been left
out and that is attribute reuse. The maven-faces-plugin allows you to
import XML fragments using XPath. So in Trinidad, onclick,
onmouseover, onmouseout, etc. you can import one XML file
On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
[1] I'm not sure what the later property examples on that page are meant
to be; as Leonardo has written them they are attached to no function
which is not what I had in mind...
The examples that does not have
On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi Andrew,
Andrew Robinson schrieb:
One major drawback to the javadoc annotation approach has been left
out and that is attribute reuse. The maven-faces-plugin allows you to
import XML fragments using XPath.
On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
[1] I'm not sure what the later property examples on that page are meant
to be; as Leonardo has written them they are attached to no function
which is not what I had in mind...
Thanks Simon for make more clear this on
Hi
I will start to work on the branch and commit changes on
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/skitching
Start by make a more complete model, changes on QdoxBuilder, creating a
QdoxUtil class, and follow the suggestions on the wiki, (we can merge this
with the
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Is this supposed to be a solution to the code replacement? I don't
recall any vote to achieve a resolution on how to go about the code
generation. From what this looks like, it looks worse than the current
trinidad plugin. Embedding data in
On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Is this supposed to be a solution to the code replacement? I don't
recall any vote to achieve a resolution on how to go about the code
generation. From what this
Hi,
joining the discussion very late...
but, let me please ask.
is this plugin still working with Trinidad :-) ?
-Matthias
On Mon, Mar 17, 2008 at 7:31 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 6:54 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
joining the discussion very late...
but, let me please ask.
is this plugin still working with Trinidad :-) ?
I believe that trinidad are not using myfaces-faces-plugin, but there are
using
Hi,
On Mon, Mar 17, 2008 at 8:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 6:54 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
joining the discussion very late...
but, let me please ask.
is this plugin still working with Trinidad :-) ?
I believe
Hi
I have made a wiki page for MyfaceBuilderPlugin here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
There is written the ideas present on the sample code, the comments on the
dev list and what I think that this plugin should looks like.
On Sat, Mar 15, 2008 at 4:11 PM, simon [EMAIL
Ok there are no objections, so I will start to commit this stuff right now.
regards
Leonardo Uribe
On Sat, 2008-03-15 at 14:35 -0500, Leonardo Uribe wrote:
Ok there are no objections, so I will start to commit this stuff right
now.
I object!
I thought that was obvious from the work of the last week..
On Sat, 2008-03-15 at 20:37 +0100, simon wrote:
On Sat, 2008-03-15 at 14:35 -0500, Leonardo Uribe wrote:
Ok there are no objections, so I will start to commit this stuff right
now.
I object!
I thought that was obvious from the work of the last week..
Ok, just wanted to get that
Ok, so, the big question is how I can help. I have a lot of comments and
ideas to be taken into account
about the approach of component generation using annotations.
For example: In trinidad, all components inherits in one way or another from
UIXComponent, but on
tomahawk we inherit directly of
Why not create some code that scan abstract component sources and create xml
files with the info and give this info to
myfaces-faces-plugin? on build project there are some files like
javax.faces.component hierarchy and all necessary info
should be on abstract component classes.
On Sat, 2008-03-15 at 15:16 -0500, Leonardo Uribe wrote:
Ok, so, the big question is how I can help. I have a lot of comments
and ideas to be taken into account
about the approach of component generation using annotations.
For example: In trinidad, all components inherits in one way or
On Sat, 2008-03-15 at 15:25 -0500, Leonardo Uribe wrote:
Why not create some code that scan abstract component sources and
create xml files with the info and give this info to
myfaces-faces-plugin? on build project there are some files like
javax.faces.component hierarchy and all necessary
Hi
The work for component generation for tomahawk and 1.2 modules is ready to
commit.
For component generation it follows abstract pattern and use myfaces faces
plugin.
For share 1.1 and 1.2 code it use maven-dependency plugin for unpack the
shared parts of the code.
The change on tomahawk
38 matches
Mail list logo
