You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2008/04/01 23:45:04 UTC
Re: MyfacesBuilderPlugin
Hi
The problem with xml files to make faces-plugin test work is now fixed.
I have a question about how myfaces-metadata works.
The idea is have one file per jar, and when the model is readed, it should
scan every artifact and merge it with the generated myfaces-metadata.xml.
I'm right or wrong (This is what I'm doing right now, and in my opinion is
the preferred way)?
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Leonardo Uribe schrieb:
> Hi
>
> I have a design question. I'm working on generate component tag
> classes using velocity.
>
> In this part it is common to found some situations when you need
> utility methods. There are several methods
> to do this:
>
> 1) Implementing this methods on a java class, and use the following
> code using a macro file on inside the template:
>
> ## [[[[[ Setting Utility Classes to use ]]]]]
> ##
> #set($utils =
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
>
> In this case, we can copy
> org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
> myfaces-faces-plugin and use it
> inside the templates. like this
>
> $utils.lowerCase($field.getAttributeValue("name"))
>
> 2) Use a file to create velocity macros and implement this here.
> Inside we need to use StringUtils like in (1), but from the point of
> view of the template designer, He/she doesn't see this.
>
> 3) Create methods on each Model and XXXMeta. Sometimes this is
> unavoidable (like getting the properties from a component) and is more
> clean. For example:
>
> package ${component.tagPackage};
>
> public class ${component.tagName}{
>
> #foreach( $property in ${component.propertyList} )
> //getter and setter methods
> #end
> }
>
> This two methods (getTagPackage and getTagName and derived properties
> of tagClass).
>
> What option could be better? If no suggestions, I will go for option 1
> and 3.
+1
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Apr 3, 2008 at 6:56 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> > The drawback
> > is that creates a log file on the project folder (I'm not found how to
> > output the log on the screen yet!).
>
> Have you looked at this page?
>
>
> http://velocity.apache.org/engine/devel/developer-guide.html#configuring_logging
>
> Here are some specific examples:
>
> http://www.java2s.com/Code/Java/Velocity/Velocity-Log.htm
>
I have readed the developer guide again and with the examples on the second
link the problem is fixed. Thanks for the tips
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by Mike Kienenberger <mk...@gmail.com>.
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> The drawback
> is that creates a log file on the project folder (I'm not found how to
> output the log on the screen yet!).
Have you looked at this page?
http://velocity.apache.org/engine/devel/developer-guide.html#configuring_logging
Here are some specific examples:
http://www.java2s.com/Code/Java/Velocity/Velocity-Log.htm
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Apr 3, 2008 at 5:33 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> I have not seen the specifics of this project, but if you're using
> velocity, you should be able to have the code which initializes
> velocity automatically populate something like $utils instead of doing
> it in the velocity template language.
>
> I also think you're better off NOT putting velocity-specific utilities
> on the data model. Determine if those methods would make sense if you
> were not using velocity, and if that's the case, keep it on a separate
> java object (By the way, these separate java objects are called
> "tools" in the velocity jargon.).
>
Good rule of thumb. Thanks
>
> I'm not sure what the ideal way of doing this from maven is, but in
> ant, we typically configured these tools using the BSD-licensed
> VPP-provided ant tasks.
>
> http://vpp.sourceforge.net/
>
>
> It's not all difficult to do this in java code, if you have direct
> control over the code setting up the Velocity engine.
>
> velocityContext.put("stringUtils", new StringUtils());
> velocityContext.put("myfacesUtils", new MyfacesUtils());
>
>
One option in maven is use plexus-velocity, but this has a problem: in this
case the velocity engine
must be initialized with some custom params. So initialization is done using
hand code. The drawback
is that creates a log file on the project folder (I'm not found how to
output the log on the screen yet!).
The idea is for each template use a Velocity context with this params
//utility
context.put("stringUtils", new StringUtils());
context.put("utils", new Utils());
....
//
context.put("component", component);
Again thanks for your suggestions
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by Mike Kienenberger <mk...@gmail.com>.
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the velocity template language.
I also think you're better off NOT putting velocity-specific utilities
on the data model. Determine if those methods would make sense if you
were not using velocity, and if that's the case, keep it on a separate
java object (By the way, these separate java objects are called
"tools" in the velocity jargon.).
I'm not sure what the ideal way of doing this from maven is, but in
ant, we typically configured these tools using the BSD-licensed
VPP-provided ant tasks.
http://vpp.sourceforge.net/
It's not all difficult to do this in java code, if you have direct
control over the code setting up the Velocity engine.
velocityContext.put("stringUtils", new StringUtils());
velocityContext.put("myfacesUtils", new MyfacesUtils());
On Wed, Apr 2, 2008 at 9:52 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> I have a design question. I'm working on generate component tag classes
> using velocity.
>
> In this part it is common to found some situations when you need utility
> methods. There are several methods
> to do this:
>
> 1) Implementing this methods on a java class, and use the following code
> using a macro file on inside the template:
>
> ## [[[[[ Setting Utility Classes to use ]]]]]
> ##
> #set($utils =
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
>
> In this case, we can copy
> org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
> myfaces-faces-plugin and use it
> inside the templates. like this
>
> $utils.lowerCase($field.getAttributeValue("name"))
>
> 2) Use a file to create velocity macros and implement this here. Inside we
> need to use StringUtils like in (1), but from the point of view of the
> template designer, He/she doesn't see this.
>
> 3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
> (like getting the properties from a component) and is more clean. For
> example:
>
> package ${component.tagPackage};
>
> public class ${component.tagName}{
>
> #foreach( $property in ${component.propertyList} )
> //getter and setter methods
> #end
> }
>
> This two methods (getTagPackage and getTagName and derived properties of
> tagClass).
>
> What option could be better? If no suggestions, I will go for option 1 and
> 3.
>
> regards
>
> Leonardo Uribe
>
>
>
> On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
> >
> >
> >
> >
> > On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at
> <si...@chello.at> wrote:
> >
> > >
> > >
> > > I'm not quite clear what your description above means. I think we are
> > > talking about the same thing, but just to be clear this is how I would
> > > see it working:
> > >
> > > == for goal build-metadata:
> > >
> > > start with an empty model
> > > for each jarfile containing a META-INF/myfaces-metadata.xml file
> > > read that myfaces-metadata.xml file
> > > add the resulting objects into the model[1]
> > > run the ModelBuilder for the current project, which adds more objects to
> > > the model
> > > save the model into META-INF/myfaces-metadata.xml in the current project
> > >
> > > An alternative would be to do the merging just at the xml level, then
> > > build a model from the resulting merged xml file. That also seems
> > > reasonable.
> > >
> > > == for other goals (eg generate faces.xml, generate tag classes):
> > > start with an empty model
> > > read META-INF/myfaces-metadata.xml for the current project only
> > > add the resulting objects to the model
> > > pass the model object to the appropriate generator class[3]
> > >
> > > [1] Hmm..might need to somehow detect and handle duplicate data.
> > >
> >
> >
> > Yes, duplicated data is the problem.
> >
> >
> > >
> > > In particular, tomahawk will depend on both myfaces-api and
> > > myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
> > > copy of all the data from the myfaces-metadata.xml contained in
> > > myfaces-api jarfile. So if *all* jars in the classpath are processed,
> > > the data from myfaces-api.jar will be processed twice.
> > >
> >
> >
> > Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
> > core depends of myfaces api only (because it should be compatible with jsf
> ri, no
> > impl dependences should be present). So the problem ilustrated here raises
> on sandbox.
> >
> >
> > >
> > > Options I see are
> > > (a) don't worry; the data will just be identical
> >
> >
> > Right.
> >
> >
> > >
> > > (b) check that if a model object is being overwritten, the new data is
> > > identical
> > > (c) have the plugin configured with an explicit list of jars to process
> > > metadata from. Then in the pom it must be configured so that
> > > myfaces-impl is processed and myfaces-api is ignored. Then make it an
> > > error for the same model object to be defined twice.
> > > (d) have a myfaces-metadata.xml file *not* include data inherited from
> > > parent projects. That's cleaner in a way, but means that when processing
> > > other goals we cannot just load the metadata file from the local project
> > > but need to merge in all the ancestor projects too. Ecch.
> > > (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
> > > they came from.
> > >
> >
> >
> > Really, the option that likes me more is (e). One option to do this is
> create a
> > modelId parameter (for components and other stuff inside Model), assigned
> on the pom as a param.
> > This param can be used in several situations:
> >
> > (a) In tomahawk core, we need to generate a hierarchy of tag classes for
> myfaces api components.
> > From this classes, tomahawk tag classes inherit. Note we need to change
> package for myfaces
> > api component tag classes group (only html components). One option is give
> the possibility to apply a XSTL
> > filter to myfaces-metadata.xml that do this.
> > (b) Specify that some goal should be applied to a specific group of
> components, identified with a modelId.
> >
> > I will test this ideas and see what happen.
> >
> > regards
> >
> > Leonardo Uribe
> >
>
>
Re: MyfacesBuilderPlugin
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Leonardo Uribe schrieb:
>
> On Wed, Apr 16, 2008 at 12:33 PM, Mike Kienenberger
> <mkienenb@gmail.com <ma...@gmail.com>> wrote:
>
> Another alternative to option 1 is to #parse($fileName) or
> #include($fileName).
> You can specify filename externally. This is probably the best
> solution so long as the contents of the file included can be included
> "as-is".
>
>
> The only problem with this solution is that you cannot do something
> like this:
>
> faces-config-base.xml
>
> <faces-config>
> <application>
> <!-- custom code -->
> </application>
> </faces-config>
>
> and include only the application part (what I want because is more
> clear for the developer). I have implemented option 1, anyway, using
> #parse or #include is also available.
Yes, the original plugin could take a full config file, and extract the
children of the document root for merging into the final result. That
was a little cleaner. I don't know enough about velocity to know if
there is a way to achieve that.
I guess a builder-plugin utility class could be written to take a
filename as input, and return the content of the root element as a
string. Then that could be called from the velocity template.
>
> Right now generation of faces-config, .tld (or any config file you
> want), component classes and tag classes works. Now I'm doing some big
> tests (use it in myfaces 1.1 and generate faces-config, .tld, and tag
> classes, then probe it on tomahawk generating all the stuff).
>
> The only part that I want to enhance of this plugin is that is very
> common that component generation can be done fully (an example is
> javax.faces.component.html classes minus HtmlDataTable). The question
> is how to add the definition of this component without creating a
> .java file and annotations or doclets to do it (maybe do a part that
> use groovy .....). My first idea is create a package scope .java class
> like _HtmlCommandButton and add the needed stuff, but this file is
> included by the compiler to the jar (does not a big problem, since has
> not side effects). So I'm looking a cleaner way to do this.
>
> suggestions are welcome
I'm ok with package-scoped classes for this case. I think it is clear to
developers what is going on, which is more important than saving a few
kb in the resulting jar. But of course the maven-jar-plugin could be
configured to exclude these empty classes when building the jarfile if
this is important. In addition, if javadoc is generated with
package-scope enabled, then we get some helpful documentation about what
is going on.
For java1.5, it is possible to write a "package.java" file. This is
intended to replace "package.html"; it allows package docs to be written
as javadoc, rather than an html fragment. It also allows package-scope
annotations to be added, which can be introspected at runtime. This
would be a possible place to put annotations that don't have a real
class to be attached to. Of course this does result in another .class
file in the jar, but that didn't seem to bother Java's architects.
Does the meta-data for these auto-generated components really have *no*
properties that can be derived from introspection of a java class? One
reason for the annotation-based approach is that properties can be
determined by analysing code rather than simply accepting string data
entered by the user. That allows at least some of the config to be
checked by the compiler, supported during refactoring, etc.
If a project uses the "real" annotations (rather than javadoc
annotations) then it becomes even more useful to have this info
expressed via .java files (rather than a .xml config file or similar).
Regards,
Simon
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Apr 16, 2008 at 12:33 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> Another alternative to option 1 is to #parse($fileName) or
> #include($fileName).
> You can specify filename externally. This is probably the best
> solution so long as the contents of the file included can be included
> "as-is".
>
The only problem with this solution is that you cannot do something like
this:
faces-config-base.xml
<faces-config>
<application>
<!-- custom code -->
</application>
</faces-config>
and include only the application part (what I want because is more clear for
the developer). I have implemented option 1, anyway, using #parse or
#include is also available.
Right now generation of faces-config, .tld (or any config file you want),
component classes and tag classes works. Now I'm doing some big tests (use
it in myfaces 1.1 and generate faces-config, .tld, and tag classes, then
probe it on tomahawk generating all the stuff).
The only part that I want to enhance of this plugin is that is very common
that component generation can be done fully (an example is
javax.faces.component.html classes minus HtmlDataTable). The question is how
to add the definition of this component without creating a .java file and
annotations or doclets to do it (maybe do a part that use groovy .....). My
first idea is create a package scope .java class like _HtmlCommandButton and
add the needed stuff, but this file is included by the compiler to the jar
(does not a big problem, since has not side effects). So I'm looking a
cleaner way to do this.
suggestions are welcome
regards
Leonardo Uribe
> On 4/9/08, Leonardo Uribe <lu...@gmail.com> wrote:
> > Hi
> >
> > I have another design question. I have finished tag class generation
> using
> > velocity, and right now I'm working on generation of component classes,
> but
> > later I want to use this tool for generate faces-config.xml and
> taglib.tld
> > files too.
> >
> > The problem is that in some point it is necessary to let the user define
> > files like faces-config-base.xml and taglib-base.xml, to add some
> content
> > inside the generated file (or in other words merge this files).
> >
> > 1. One option is use velocity like this:
> >
> > <faces-config>
> > $customContentFromFacesConfigBase
> >
> > <!-- generated xml content -->
> >
> > </faces-config>
> >
> > 2. But another solution is try to merge this files with some xml tool.
> >
> > 3. Other solution is provide what we want to insert what we need to add
> on
> > the template that are readed from
> > mylib/src/main/resources/META-INF/templateForFacesConfig.vm
> >
> > What option could be better? If no suggestions I will go with option 3
> (the
> > easy the better, but option 1 sound good too).
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
>
Re: MyfacesBuilderPlugin
Posted by Mike Kienenberger <mk...@gmail.com>.
Another alternative to option 1 is to #parse($fileName) or #include($fileName).
You can specify filename externally. This is probably the best
solution so long as the contents of the file included can be included
"as-is".
On 4/9/08, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> I have another design question. I have finished tag class generation using
> velocity, and right now I'm working on generation of component classes, but
> later I want to use this tool for generate faces-config.xml and taglib.tld
> files too.
>
> The problem is that in some point it is necessary to let the user define
> files like faces-config-base.xml and taglib-base.xml, to add some content
> inside the generated file (or in other words merge this files).
>
> 1. One option is use velocity like this:
>
> <faces-config>
> $customContentFromFacesConfigBase
>
> <!-- generated xml content -->
>
> </faces-config>
>
> 2. But another solution is try to merge this files with some xml tool.
>
> 3. Other solution is provide what we want to insert what we need to add on
> the template that are readed from
> mylib/src/main/resources/META-INF/templateForFacesConfig.vm
>
> What option could be better? If no suggestions I will go with option 3 (the
> easy the better, but option 1 sound good too).
>
> regards
>
> Leonardo Uribe
>
>
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have another design question. I have finished tag class generation using
velocity, and right now I'm working on generation of component classes, but
later I want to use this tool for generate faces-config.xml and taglib.tld
files too.
The problem is that in some point it is necessary to let the user define
files like faces-config-base.xml and taglib-base.xml, to add some content
inside the generated file (or in other words merge this files).
1. One option is use velocity like this:
<faces-config>
$customContentFromFacesConfigBase
<!-- generated xml content -->
</faces-config>
2. But another solution is try to merge this files with some xml tool.
3. Other solution is provide what we want to insert what we need to add on
the template that are readed from
mylib/src/main/resources/META-INF/templateForFacesConfig.vm
What option could be better? If no suggestions I will go with option 3 (the
easy the better, but option 1 sound good too).
regards
Leonardo Uribe
RE: MyfacesBuilderPlugin
Posted by "Kito D. Mann" <km...@virtua.com>.
Simon,
Thanks for the recap. Guess I missed that discussion :-).
Whenever you guys get this one out of the door, make sure you devote an obvious Wiki location for it. That way, it'll be easier for people to document it. That’s a major issue with the Trinidad plugins :-).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
> -----Original Message-----
> From: simon [mailto:simon.kitching@chello.at]
> Sent: Friday, April 04, 2008 2:29 AM
> To: 'MyFaces Development'
> Cc: Kito D. Mann
> Subject: RE: MyfacesBuilderPlugin
>
>
> On Thu, 2008-04-03 at 20:29 -0400, Kito D. Mann wrote:
> > Thanks for the explanation, Leonardo. I’m guessing that the Trinidad
> > plugin isn’t generic enough to be used outside of Trinidad?
>
> No, the Trinidad plugin could be used elsewhere. In fact it has been
> used to build the myfaces-core 1.2.0 and 1.2.2 releases.
>
> Work was then done to rename it to "myfaces-faces-plugin" just for
> tidiness (not released yet, but probably "late beta" state as it's
> mostly a rename of existing code). Some work was then done to start
> converting Tomahawk to use this (beta) plugin.
>
> But then there was a lot of discussion on the dev list; some people
> (particularly me) did not think the trinidad-plugin approach was very
> elegant, and did not want it to spread across the whole set of myfaces
> projects. You can see the discussion in the mail archives, and more
> info
> here:
> http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
>
> As there was reasonable support for an alternative "annotation-driven"
> approach, I created a prototype implementation. People seem reasonably
> happy with the approach, and Leonardo is now doing some great work
> extending the initial code (in particular, adding the "back end" part).
> This new plugin is 95% new code, with just a little bit borrowed from
> the trinidad plugin project.
>
> At some point I guess there will need to be an official vote on which
> plugin will be used for myfaces core 1.1, core1.2 and tomahawk. *If*
> the
> "myfaces-builder-plugin" is chosen, then the Trinidad team will need to
> decide whether to stay with their existing plugin or change over.
> Tobago
> has its own plugin for similar purposes; their approach is much more
> like the myfaces-builder-plugin proposal than the trinidad-plugin
> approach. Again, it would be up to the Tobago team to decide whether to
> try to join forces or not.
>
> Regards,
> Simon
>
>
>
>
>
> >
> > From: Leonardo Uribe [mailto:lu4242@gmail.com]
> > Sent: Thursday, April 03, 2008 7:50 PM
> > To: MyFaces Development; kmann@virtua.com
> > Subject: Re: MyfacesBuilderPlugin
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <km...@virtua.com>
> > wrote:
> >
> > Is the MyfacesBuilderPlugin completely separate from the Trinidad
> > Maven Plugins?
> >
> >
> >
> > Actually is a branch developed inside build-tools. There is no
> > official vote yet about if this plugin will be used on trinidad,
> since
> > myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are
> > working and works very well. Theorically, after a votation this
> plugin
> > could be used on myfaces and tomahawk.
> >
> >
> >
> >
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Kito D. Mann - Author, JavaServer Faces in Action
> > http://www.virtua.com - JSF/Java EE consulting, training, and
> > mentoring
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and
> > info
> > phone: +1 203-653-2989
> > fax: +1 203-653-2988
> >
> >
> >
> > From: Leonardo Uribe [mailto:lu4242@gmail.com]
> > Sent: Wednesday, April 02, 2008 9:53 PM
> > To: MyFaces Development
> > Subject: Re: MyfacesBuilderPlugin
> >
> >
> >
> >
> > Hi
> >
> > I have a design question. I'm working on generate component
> > tag classes using velocity.
> >
> > In this part it is common to found some situations when you
> > need utility methods. There are several methods
> > to do this:
> >
> > 1) Implementing this methods on a java class, and use the
> > following code using a macro file on inside the template:
> >
> > ## [[[[[ Setting Utility Classes to use ]]]]]
> > ##
> > #set($utils =
> >
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
> >
> > In this case, we can copy
> > org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util
> > form myfaces-faces-plugin and use it
> > inside the templates. like this
> >
> > $utils.lowerCase($field.getAttributeValue("name"))
> >
> > 2) Use a file to create velocity macros and implement this
> > here. Inside we need to use StringUtils like in (1), but from
> > the point of view of the template designer, He/she doesn't
> see
> > this.
> >
> > 3) Create methods on each Model and XXXMeta. Sometimes this
> is
> > unavoidable (like getting the properties from a component)
> and
> > is more clean. For example:
> >
> > package ${component.tagPackage};
> >
> > public class ${component.tagName}{
> >
> > #foreach( $property in ${component.propertyList} )
> > //getter and setter methods
> > #end
> > }
> >
> > This two methods (getTagPackage and getTagName and derived
> > properties of tagClass).
> >
> > What option could be better? If no suggestions, I will go for
> > option 1 and 3.
> >
> > regards
> >
> > Leonardo Uribe
> >
> > On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe
> > <lu...@gmail.com> wrote:
> >
> >
> >
> > On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at
> > <si...@chello.at> wrote:
> >
> >
> >
> >
> > I'm not quite clear what your description above means. I
> think
> > we are
> > talking about the same thing, but just to be clear this is
> how
> > I would
> > see it working:
> >
> > == for goal build-metadata:
> >
> > start with an empty model
> > for each jarfile containing a META-INF/myfaces-metadata.xml
> > file
> > read that myfaces-metadata.xml file
> > add the resulting objects into the model[1]
> > run the ModelBuilder for the current project, which adds more
> > objects to
> > the model
> > save the model into META-INF/myfaces-metadata.xml in the
> > current project
> >
> > An alternative would be to do the merging just at the xml
> > level, then
> > build a model from the resulting merged xml file. That also
> > seems
> > reasonable.
> >
> > == for other goals (eg generate faces.xml, generate tag
> > classes):
> > start with an empty model
> > read META-INF/myfaces-metadata.xml for the current project
> > only
> > add the resulting objects to the model
> > pass the model object to the appropriate generator class[3]
> >
> > [1] Hmm..might need to somehow detect and handle duplicate
> > data.
> >
> >
> >
> > Yes, duplicated data is the problem.
> >
> >
> >
> >
> > In particular, tomahawk will depend on both
> > myfaces-api and
> > myfaces-impl. But the META-INF/myfaces-metadata.xml
> > file will have a
> > copy of all the data from the myfaces-metadata.xml
> > contained in
> > myfaces-api jarfile. So if *all* jars in the
> classpath
> > are processed,
> > the data from myfaces-api.jar will be processed
> twice.
> >
> >
> > Tomahawk sandbox depends on tomahawk core and myfaces api.
> > Tomahawk
> > core depends of myfaces api only (because it should be
> > compatible with jsf ri, no
> > impl dependences should be present). So the problem
> ilustrated
> > here raises on sandbox.
> >
> >
> >
> >
> > Options I see are
> > (a) don't worry; the data will just be identical
> >
> >
> > Right.
> >
> >
> >
> >
> > (b) check that if a model object is being
> overwritten,
> > the new data is
> > identical
> > (c) have the plugin configured with an explicit list
> > of jars to process
> > metadata from. Then in the pom it must be configured
> > so that
> > myfaces-impl is processed and myfaces-api is ignored.
> > Then make it an
> > error for the same model object to be defined twice.
> > (d) have a myfaces-metadata.xml file *not* include
> > data inherited from
> > parent projects. That's cleaner in a way, but means
> > that when processing
> > other goals we cannot just load the metadata file
> from
> > the local project
> > but need to merge in all the ancestor projects too.
> > Ecch.
> > (e) in the myfaces-metadata.xml, somehow mark entries
> > with the jarfile
> > they came from.
> >
> >
> > Really, the option that likes me more is (e). One option to
> do
> > this is create a
> > modelId parameter (for components and other stuff inside
> > Model), assigned on the pom as a param.
> > This param can be used in several situations:
> >
> > (a) In tomahawk core, we need to generate a hierarchy of tag
> > classes for myfaces api components.
> > >From this classes, tomahawk tag classes inherit. Note we
> need
> > to change package for myfaces
> > api component tag classes group (only html components). One
> > option is give the possibility to apply a XSTL
> > filter to myfaces-metadata.xml that do this.
> > (b) Specify that some goal should be applied to a specific
> > group of components, identified with a modelId.
> >
> >
> >
> > I will test this ideas and see what happen.
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> >
> >
> >
> >
> >
> >
RE: MyfacesBuilderPlugin
Posted by simon <si...@chello.at>.
On Thu, 2008-04-03 at 20:29 -0400, Kito D. Mann wrote:
> Thanks for the explanation, Leonardo. I’m guessing that the Trinidad
> plugin isn’t generic enough to be used outside of Trinidad?
No, the Trinidad plugin could be used elsewhere. In fact it has been
used to build the myfaces-core 1.2.0 and 1.2.2 releases.
Work was then done to rename it to "myfaces-faces-plugin" just for
tidiness (not released yet, but probably "late beta" state as it's
mostly a rename of existing code). Some work was then done to start
converting Tomahawk to use this (beta) plugin.
But then there was a lot of discussion on the dev list; some people
(particularly me) did not think the trinidad-plugin approach was very
elegant, and did not want it to spread across the whole set of myfaces
projects. You can see the discussion in the mail archives, and more info
here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
As there was reasonable support for an alternative "annotation-driven"
approach, I created a prototype implementation. People seem reasonably
happy with the approach, and Leonardo is now doing some great work
extending the initial code (in particular, adding the "back end" part).
This new plugin is 95% new code, with just a little bit borrowed from
the trinidad plugin project.
At some point I guess there will need to be an official vote on which
plugin will be used for myfaces core 1.1, core1.2 and tomahawk. *If* the
"myfaces-builder-plugin" is chosen, then the Trinidad team will need to
decide whether to stay with their existing plugin or change over. Tobago
has its own plugin for similar purposes; their approach is much more
like the myfaces-builder-plugin proposal than the trinidad-plugin
approach. Again, it would be up to the Tobago team to decide whether to
try to join forces or not.
Regards,
Simon
>
> From: Leonardo Uribe [mailto:lu4242@gmail.com]
> Sent: Thursday, April 03, 2008 7:50 PM
> To: MyFaces Development; kmann@virtua.com
> Subject: Re: MyfacesBuilderPlugin
>
>
>
>
>
>
> On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <km...@virtua.com>
> wrote:
>
> Is the MyfacesBuilderPlugin completely separate from the Trinidad
> Maven Plugins?
>
>
>
> Actually is a branch developed inside build-tools. There is no
> official vote yet about if this plugin will be used on trinidad, since
> myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are
> working and works very well. Theorically, after a votation this plugin
> could be used on myfaces and tomahawk.
>
>
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and
> mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and
> info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>
> From: Leonardo Uribe [mailto:lu4242@gmail.com]
> Sent: Wednesday, April 02, 2008 9:53 PM
> To: MyFaces Development
> Subject: Re: MyfacesBuilderPlugin
>
>
>
>
> Hi
>
> I have a design question. I'm working on generate component
> tag classes using velocity.
>
> In this part it is common to found some situations when you
> need utility methods. There are several methods
> to do this:
>
> 1) Implementing this methods on a java class, and use the
> following code using a macro file on inside the template:
>
> ## [[[[[ Setting Utility Classes to use ]]]]]
> ##
> #set($utils =
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
>
> In this case, we can copy
> org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util
> form myfaces-faces-plugin and use it
> inside the templates. like this
>
> $utils.lowerCase($field.getAttributeValue("name"))
>
> 2) Use a file to create velocity macros and implement this
> here. Inside we need to use StringUtils like in (1), but from
> the point of view of the template designer, He/she doesn't see
> this.
>
> 3) Create methods on each Model and XXXMeta. Sometimes this is
> unavoidable (like getting the properties from a component) and
> is more clean. For example:
>
> package ${component.tagPackage};
>
> public class ${component.tagName}{
>
> #foreach( $property in ${component.propertyList} )
> //getter and setter methods
> #end
> }
>
> This two methods (getTagPackage and getTagName and derived
> properties of tagClass).
>
> What option could be better? If no suggestions, I will go for
> option 1 and 3.
>
> regards
>
> Leonardo Uribe
>
> On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe
> <lu...@gmail.com> wrote:
>
>
>
> On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at
> <si...@chello.at> wrote:
>
>
>
>
> I'm not quite clear what your description above means. I think
> we are
> talking about the same thing, but just to be clear this is how
> I would
> see it working:
>
> == for goal build-metadata:
>
> start with an empty model
> for each jarfile containing a META-INF/myfaces-metadata.xml
> file
> read that myfaces-metadata.xml file
> add the resulting objects into the model[1]
> run the ModelBuilder for the current project, which adds more
> objects to
> the model
> save the model into META-INF/myfaces-metadata.xml in the
> current project
>
> An alternative would be to do the merging just at the xml
> level, then
> build a model from the resulting merged xml file. That also
> seems
> reasonable.
>
> == for other goals (eg generate faces.xml, generate tag
> classes):
> start with an empty model
> read META-INF/myfaces-metadata.xml for the current project
> only
> add the resulting objects to the model
> pass the model object to the appropriate generator class[3]
>
> [1] Hmm..might need to somehow detect and handle duplicate
> data.
>
>
>
> Yes, duplicated data is the problem.
>
>
>
>
> In particular, tomahawk will depend on both
> myfaces-api and
> myfaces-impl. But the META-INF/myfaces-metadata.xml
> file will have a
> copy of all the data from the myfaces-metadata.xml
> contained in
> myfaces-api jarfile. So if *all* jars in the classpath
> are processed,
> the data from myfaces-api.jar will be processed twice.
>
>
> Tomahawk sandbox depends on tomahawk core and myfaces api.
> Tomahawk
> core depends of myfaces api only (because it should be
> compatible with jsf ri, no
> impl dependences should be present). So the problem ilustrated
> here raises on sandbox.
>
>
>
>
> Options I see are
> (a) don't worry; the data will just be identical
>
>
> Right.
>
>
>
>
> (b) check that if a model object is being overwritten,
> the new data is
> identical
> (c) have the plugin configured with an explicit list
> of jars to process
> metadata from. Then in the pom it must be configured
> so that
> myfaces-impl is processed and myfaces-api is ignored.
> Then make it an
> error for the same model object to be defined twice.
> (d) have a myfaces-metadata.xml file *not* include
> data inherited from
> parent projects. That's cleaner in a way, but means
> that when processing
> other goals we cannot just load the metadata file from
> the local project
> but need to merge in all the ancestor projects too.
> Ecch.
> (e) in the myfaces-metadata.xml, somehow mark entries
> with the jarfile
> they came from.
>
>
> Really, the option that likes me more is (e). One option to do
> this is create a
> modelId parameter (for components and other stuff inside
> Model), assigned on the pom as a param.
> This param can be used in several situations:
>
> (a) In tomahawk core, we need to generate a hierarchy of tag
> classes for myfaces api components.
> >From this classes, tomahawk tag classes inherit. Note we need
> to change package for myfaces
> api component tag classes group (only html components). One
> option is give the possibility to apply a XSTL
> filter to myfaces-metadata.xml that do this.
> (b) Specify that some goal should be applied to a specific
> group of components, identified with a modelId.
>
>
>
> I will test this ideas and see what happen.
>
> regards
>
> Leonardo Uribe
>
>
>
>
>
>
>
>
RE: MyfacesBuilderPlugin
Posted by "Kito D. Mann" <km...@virtua.com>.
Thanks for the explanation, Leonardo. I'm guessing that the Trinidad plugin
isn't generic enough to be used outside of Trinidad?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
From: Leonardo Uribe [mailto:lu4242@gmail.com]
Sent: Thursday, April 03, 2008 7:50 PM
To: MyFaces Development; kmann@virtua.com
Subject: Re: MyfacesBuilderPlugin
On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <km...@virtua.com> wrote:
Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
Plugins?
Actually is a branch developed inside build-tools. There is no official vote
yet about if this plugin will be used on trinidad, since
myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are working
and works very well. Theorically, after a votation this plugin could be used
on myfaces and tomahawk.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
From: Leonardo Uribe [mailto:lu4242@gmail.com]
Sent: Wednesday, April 02, 2008 9:53 PM
To: MyFaces Development
Subject: Re: MyfacesBuilderPlugin
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a macro file on inside the template:
## [[[[[ Setting Utility Classes to use ]]]]]
##
#set($utils =
$classes.forName("org.apache.commons.lang.StringUtils").newInstance())
In this case, we can copy
org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
myfaces-faces-plugin and use it
inside the templates. like this
$utils.lowerCase($field.getAttributeValue("name"))
2) Use a file to create velocity macros and implement this here. Inside we
need to use StringUtils like in (1), but from the point of view of the
template designer, He/she doesn't see this.
3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
(like getting the properties from a component) and is more clean. For
example:
package ${component.tagPackage};
public class ${component.tagName}{
#foreach( $property in ${component.propertyList} )
//getter and setter methods
#end
}
This two methods (getTagPackage and getTagName and derived properties of
tagClass).
What option could be better? If no suggestions, I will go for option 1 and
3.
regards
Leonardo Uribe
On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <lu...@gmail.com> wrote:
On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at
<si...@chello.at> wrote:
I'm not quite clear what your description above means. I think we are
talking about the same thing, but just to be clear this is how I would
see it working:
== for goal build-metadata:
start with an empty model
for each jarfile containing a META-INF/myfaces-metadata.xml file
read that myfaces-metadata.xml file
add the resulting objects into the model[1]
run the ModelBuilder for the current project, which adds more objects to
the model
save the model into META-INF/myfaces-metadata.xml in the current project
An alternative would be to do the merging just at the xml level, then
build a model from the resulting merged xml file. That also seems
reasonable.
== for other goals (eg generate faces.xml, generate tag classes):
start with an empty model
read META-INF/myfaces-metadata.xml for the current project only
add the resulting objects to the model
pass the model object to the appropriate generator class[3]
[1] Hmm..might need to somehow detect and handle duplicate data.
Yes, duplicated data is the problem.
In particular, tomahawk will depend on both myfaces-api and
myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
copy of all the data from the myfaces-metadata.xml contained in
myfaces-api jarfile. So if *all* jars in the classpath are processed,
the data from myfaces-api.jar will be processed twice.
Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
core depends of myfaces api only (because it should be compatible with jsf
ri, no
impl dependences should be present). So the problem ilustrated here raises
on sandbox.
Options I see are
(a) don't worry; the data will just be identical
Right.
(b) check that if a model object is being overwritten, the new data is
identical
(c) have the plugin configured with an explicit list of jars to process
metadata from. Then in the pom it must be configured so that
myfaces-impl is processed and myfaces-api is ignored. Then make it an
error for the same model object to be defined twice.
(d) have a myfaces-metadata.xml file *not* include data inherited from
parent projects. That's cleaner in a way, but means that when processing
other goals we cannot just load the metadata file from the local project
but need to merge in all the ancestor projects too. Ecch.
(e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
they came from.
Really, the option that likes me more is (e). One option to do this is
create a
modelId parameter (for components and other stuff inside Model), assigned on
the pom as a param.
This param can be used in several situations:
(a) In tomahawk core, we need to generate a hierarchy of tag classes for
myfaces api components.
>>From this classes, tomahawk tag classes inherit. Note we need to change
package for myfaces
api component tag classes group (only html components). One option is give
the possibility to apply a XSTL
filter to myfaces-metadata.xml that do this.
(b) Specify that some goal should be applied to a specific group of
components, identified with a modelId.
I will test this ideas and see what happen.
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <km...@virtua.com> wrote:
> Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
> Plugins?
>
>
Actually is a branch developed inside build-tools. There is no official vote
yet about if this plugin will be used on trinidad, since
myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are working
and works very well. Theorically, after a votation this plugin could be used
on myfaces and tomahawk.
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces
> FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>
> *From:* Leonardo Uribe [mailto:lu4242@gmail.com]
> *Sent:* Wednesday, April 02, 2008 9:53 PM
> *To:* MyFaces Development
> *Subject:* Re: MyfacesBuilderPlugin
>
>
>
> Hi
>
> I have a design question. I'm working on generate component tag classes
> using velocity.
>
> In this part it is common to found some situations when you need utility
> methods. There are several methods
> to do this:
>
> 1) Implementing this methods on a java class, and use the following code
> using a macro file on inside the template:
>
> ## [[[[[ Setting Utility Classes to use ]]]]]
> ##
> #set($utils =
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
>
> In this case, we can copy
> org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
> myfaces-faces-plugin and use it
> inside the templates. like this
>
> $utils.lowerCase($field.getAttributeValue("name"))
>
> 2) Use a file to create velocity macros and implement this here. Inside we
> need to use StringUtils like in (1), but from the point of view of the
> template designer, He/she doesn't see this.
>
> 3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
> (like getting the properties from a component) and is more clean. For
> example:
>
> package ${component.tagPackage};
>
> public class ${component.tagName}{
>
> #foreach( $property in ${component.propertyList} )
> //getter and setter methods
> #end
> }
>
> This two methods (getTagPackage and getTagName and derived properties of
> tagClass).
>
> What option could be better? If no suggestions, I will go for option 1 and
> 3.
>
> regards
>
> Leonardo Uribe
>
> On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
>
> On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at <
> simon.kitching@chello.at> wrote:
>
>
>
> I'm not quite clear what your description above means. I think we are
> talking about the same thing, but just to be clear this is how I would
> see it working:
>
> == for goal build-metadata:
>
> start with an empty model
> for each jarfile containing a META-INF/myfaces-metadata.xml file
> read that myfaces-metadata.xml file
> add the resulting objects into the model[1]
> run the ModelBuilder for the current project, which adds more objects to
> the model
> save the model into META-INF/myfaces-metadata.xml in the current project
>
> An alternative would be to do the merging just at the xml level, then
> build a model from the resulting merged xml file. That also seems
> reasonable.
>
> == for other goals (eg generate faces.xml, generate tag classes):
> start with an empty model
> read META-INF/myfaces-metadata.xml for the current project only
> add the resulting objects to the model
> pass the model object to the appropriate generator class[3]
>
> [1] Hmm..might need to somehow detect and handle duplicate data.
>
>
> Yes, duplicated data is the problem.
>
>
>
> In particular, tomahawk will depend on both myfaces-api and
> myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
> copy of all the data from the myfaces-metadata.xml contained in
> myfaces-api jarfile. So if *all* jars in the classpath are processed,
> the data from myfaces-api.jar will be processed twice.
>
>
> Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
> core depends of myfaces api only (because it should be compatible with jsf
> ri, no
> impl dependences should be present). So the problem ilustrated here raises
> on sandbox.
>
>
>
> Options I see are
> (a) don't worry; the data will just be identical
>
>
> Right.
>
>
>
> (b) check that if a model object is being overwritten, the new data is
> identical
> (c) have the plugin configured with an explicit list of jars to process
> metadata from. Then in the pom it must be configured so that
> myfaces-impl is processed and myfaces-api is ignored. Then make it an
> error for the same model object to be defined twice.
> (d) have a myfaces-metadata.xml file *not* include data inherited from
> parent projects. That's cleaner in a way, but means that when processing
> other goals we cannot just load the metadata file from the local project
> but need to merge in all the ancestor projects too. Ecch.
> (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
> they came from.
>
>
> Really, the option that likes me more is (e). One option to do this is
> create a
> modelId parameter (for components and other stuff inside Model), assigned
> on the pom as a param.
> This param can be used in several situations:
>
> (a) In tomahawk core, we need to generate a hierarchy of tag classes for
> myfaces api components.
> From this classes, tomahawk tag classes inherit. Note we need to change
> package for myfaces
> api component tag classes group (only html components). One option is give
> the possibility to apply a XSTL
> filter to myfaces-metadata.xml that do this.
> (b) Specify that some goal should be applied to a specific group of
> components, identified with a modelId.
>
>
> I will test this ideas and see what happen.
>
> regards
>
> Leonardo Uribe
>
>
>
RE: MyfacesBuilderPlugin
Posted by "Kito D. Mann" <km...@virtua.com>.
Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
Plugins?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
From: Leonardo Uribe [mailto:lu4242@gmail.com]
Sent: Wednesday, April 02, 2008 9:53 PM
To: MyFaces Development
Subject: Re: MyfacesBuilderPlugin
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a macro file on inside the template:
## [[[[[ Setting Utility Classes to use ]]]]]
##
#set($utils =
$classes.forName("org.apache.commons.lang.StringUtils").newInstance())
In this case, we can copy
org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
myfaces-faces-plugin and use it
inside the templates. like this
$utils.lowerCase($field.getAttributeValue("name"))
2) Use a file to create velocity macros and implement this here. Inside we
need to use StringUtils like in (1), but from the point of view of the
template designer, He/she doesn't see this.
3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
(like getting the properties from a component) and is more clean. For
example:
package ${component.tagPackage};
public class ${component.tagName}{
#foreach( $property in ${component.propertyList} )
//getter and setter methods
#end
}
This two methods (getTagPackage and getTagName and derived properties of
tagClass).
What option could be better? If no suggestions, I will go for option 1 and
3.
regards
Leonardo Uribe
On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <lu...@gmail.com> wrote:
On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at
<si...@chello.at> wrote:
I'm not quite clear what your description above means. I think we are
talking about the same thing, but just to be clear this is how I would
see it working:
== for goal build-metadata:
start with an empty model
for each jarfile containing a META-INF/myfaces-metadata.xml file
read that myfaces-metadata.xml file
add the resulting objects into the model[1]
run the ModelBuilder for the current project, which adds more objects to
the model
save the model into META-INF/myfaces-metadata.xml in the current project
An alternative would be to do the merging just at the xml level, then
build a model from the resulting merged xml file. That also seems
reasonable.
== for other goals (eg generate faces.xml, generate tag classes):
start with an empty model
read META-INF/myfaces-metadata.xml for the current project only
add the resulting objects to the model
pass the model object to the appropriate generator class[3]
[1] Hmm..might need to somehow detect and handle duplicate data.
Yes, duplicated data is the problem.
In particular, tomahawk will depend on both myfaces-api and
myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
copy of all the data from the myfaces-metadata.xml contained in
myfaces-api jarfile. So if *all* jars in the classpath are processed,
the data from myfaces-api.jar will be processed twice.
Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
core depends of myfaces api only (because it should be compatible with jsf
ri, no
impl dependences should be present). So the problem ilustrated here raises
on sandbox.
Options I see are
(a) don't worry; the data will just be identical
Right.
(b) check that if a model object is being overwritten, the new data is
identical
(c) have the plugin configured with an explicit list of jars to process
metadata from. Then in the pom it must be configured so that
myfaces-impl is processed and myfaces-api is ignored. Then make it an
error for the same model object to be defined twice.
(d) have a myfaces-metadata.xml file *not* include data inherited from
parent projects. That's cleaner in a way, but means that when processing
other goals we cannot just load the metadata file from the local project
but need to merge in all the ancestor projects too. Ecch.
(e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
they came from.
Really, the option that likes me more is (e). One option to do this is
create a
modelId parameter (for components and other stuff inside Model), assigned on
the pom as a param.
This param can be used in several situations:
(a) In tomahawk core, we need to generate a hierarchy of tag classes for
myfaces api components.
>From this classes, tomahawk tag classes inherit. Note we need to change
package for myfaces
api component tag classes group (only html components). One option is give
the possibility to apply a XSTL
filter to myfaces-metadata.xml that do this.
(b) Specify that some goal should be applied to a specific group of
components, identified with a modelId.
I will test this ideas and see what happen.
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a macro file on inside the template:
## [[[[[ Setting Utility Classes to use ]]]]]
##
#set($utils =
$classes.forName("org.apache.commons.lang.StringUtils").newInstance())
In this case, we can copy
org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
myfaces-faces-plugin and use it
inside the templates. like this
$utils.lowerCase($field.getAttributeValue("name"))
2) Use a file to create velocity macros and implement this here. Inside we
need to use StringUtils like in (1), but from the point of view of the
template designer, He/she doesn't see this.
3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
(like getting the properties from a component) and is more clean. For
example:
package ${component.tagPackage};
public class ${component.tagName}{
#foreach( $property in ${component.propertyList} )
//getter and setter methods
#end
}
This two methods (getTagPackage and getTagName and derived properties of
tagClass).
What option could be better? If no suggestions, I will go for option 1 and
3.
regards
Leonardo Uribe
On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>
> On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at <
> simon.kitching@chello.at> wrote:
>
> >
> > I'm not quite clear what your description above means. I think we are
> > talking about the same thing, but just to be clear this is how I would
> > see it working:
> >
> > == for goal build-metadata:
> >
> > start with an empty model
> > for each jarfile containing a META-INF/myfaces-metadata.xml file
> > read that myfaces-metadata.xml file
> > add the resulting objects into the model[1]
> > run the ModelBuilder for the current project, which adds more objects to
> > the model
> > save the model into META-INF/myfaces-metadata.xml in the current project
> >
> > An alternative would be to do the merging just at the xml level, then
> > build a model from the resulting merged xml file. That also seems
> > reasonable.
> >
> > == for other goals (eg generate faces.xml, generate tag classes):
> > start with an empty model
> > read META-INF/myfaces-metadata.xml for the current project only
> > add the resulting objects to the model
> > pass the model object to the appropriate generator class[3]
> >
> > [1] Hmm..might need to somehow detect and handle duplicate data.
> >
>
> Yes, duplicated data is the problem.
>
>
> >
> > In particular, tomahawk will depend on both myfaces-api and
> > myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
> > copy of all the data from the myfaces-metadata.xml contained in
> > myfaces-api jarfile. So if *all* jars in the classpath are processed,
> > the data from myfaces-api.jar will be processed twice.
> >
>
> Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
> core depends of myfaces api only (because it should be compatible with jsf
> ri, no
> impl dependences should be present). So the problem ilustrated here raises
> on sandbox.
>
>
> >
> > Options I see are
> > (a) don't worry; the data will just be identical
>
>
> Right.
>
>
> >
> > (b) check that if a model object is being overwritten, the new data is
> > identical
> > (c) have the plugin configured with an explicit list of jars to process
> > metadata from. Then in the pom it must be configured so that
> > myfaces-impl is processed and myfaces-api is ignored. Then make it an
> > error for the same model object to be defined twice.
> > (d) have a myfaces-metadata.xml file *not* include data inherited from
> > parent projects. That's cleaner in a way, but means that when processing
> > other goals we cannot just load the metadata file from the local project
> > but need to merge in all the ancestor projects too. Ecch.
> > (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
> > they came from.
> >
>
> Really, the option that likes me more is (e). One option to do this is
> create a
> modelId parameter (for components and other stuff inside Model), assigned
> on the pom as a param.
> This param can be used in several situations:
>
> (a) In tomahawk core, we need to generate a hierarchy of tag classes for
> myfaces api components.
> From this classes, tomahawk tag classes inherit. Note we need to change
> package for myfaces
> api component tag classes group (only html components). One option is give
> the possibility to apply a XSTL
> filter to myfaces-metadata.xml that do this.
> (b) Specify that some goal should be applied to a specific group of
> components, identified with a modelId.
>
> I will test this ideas and see what happen.
>
> regards
>
> Leonardo Uribe
>
Re: MyfacesBuilderPlugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Apr 2, 2008 at 2:49 AM, simon.kitching@chello.at <
simon.kitching@chello.at> wrote:
>
> I'm not quite clear what your description above means. I think we are
> talking about the same thing, but just to be clear this is how I would
> see it working:
>
> == for goal build-metadata:
>
> start with an empty model
> for each jarfile containing a META-INF/myfaces-metadata.xml file
> read that myfaces-metadata.xml file
> add the resulting objects into the model[1]
> run the ModelBuilder for the current project, which adds more objects to
> the model
> save the model into META-INF/myfaces-metadata.xml in the current project
>
> An alternative would be to do the merging just at the xml level, then
> build a model from the resulting merged xml file. That also seems
> reasonable.
>
> == for other goals (eg generate faces.xml, generate tag classes):
> start with an empty model
> read META-INF/myfaces-metadata.xml for the current project only
> add the resulting objects to the model
> pass the model object to the appropriate generator class[3]
>
> [1] Hmm..might need to somehow detect and handle duplicate data.
>
Yes, duplicated data is the problem.
>
> In particular, tomahawk will depend on both myfaces-api and
> myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
> copy of all the data from the myfaces-metadata.xml contained in
> myfaces-api jarfile. So if *all* jars in the classpath are processed,
> the data from myfaces-api.jar will be processed twice.
>
Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
core depends of myfaces api only (because it should be compatible with jsf
ri, no
impl dependences should be present). So the problem ilustrated here raises
on sandbox.
>
> Options I see are
> (a) don't worry; the data will just be identical
Right.
>
> (b) check that if a model object is being overwritten, the new data is
> identical
> (c) have the plugin configured with an explicit list of jars to process
> metadata from. Then in the pom it must be configured so that
> myfaces-impl is processed and myfaces-api is ignored. Then make it an
> error for the same model object to be defined twice.
> (d) have a myfaces-metadata.xml file *not* include data inherited from
> parent projects. That's cleaner in a way, but means that when processing
> other goals we cannot just load the metadata file from the local project
> but need to merge in all the ancestor projects too. Ecch.
> (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
> they came from.
>
Really, the option that likes me more is (e). One option to do this is
create a
modelId parameter (for components and other stuff inside Model), assigned on
the pom as a param.
This param can be used in several situations:
(a) In tomahawk core, we need to generate a hierarchy of tag classes for
myfaces api components.
>From this classes, tomahawk tag classes inherit. Note we need to change
package for myfaces
api component tag classes group (only html components). One option is give
the possibility to apply a XSTL
filter to myfaces-metadata.xml that do this.
(b) Specify that some goal should be applied to a specific group of
components, identified with a modelId.
I will test this ideas and see what happen.
regards
Leonardo Uribe
Re: MyfacesBuilderPlugin
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Leonardo Uribe schrieb:
> Hi
>
> The problem with xml files to make faces-plugin test work is now fixed.
Great.
>
> I have a question about how myfaces-metadata works.
>
> The idea is have one file per jar, and when the model is readed, it
> should scan every artifact and merge it with the generated
> myfaces-metadata.xml. I'm right or wrong (This is what I'm doing right
> now, and in my opinion is the preferred way)?
I'm not quite clear what your description above means. I think we are
talking about the same thing, but just to be clear this is how I would
see it working:
== for goal build-metadata:
start with an empty model
for each jarfile containing a META-INF/myfaces-metadata.xml file
read that myfaces-metadata.xml file
add the resulting objects into the model[1]
run the ModelBuilder for the current project, which adds more objects to
the model
save the model into META-INF/myfaces-metadata.xml in the current project
An alternative would be to do the merging just at the xml level, then
build a model from the resulting merged xml file. That also seems
reasonable.
== for other goals (eg generate faces.xml, generate tag classes):
start with an empty model
read META-INF/myfaces-metadata.xml for the current project only
add the resulting objects to the model
pass the model object to the appropriate generator class[3]
[1] Hmm..might need to somehow detect and handle duplicate data.
In particular, tomahawk will depend on both myfaces-api and
myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
copy of all the data from the myfaces-metadata.xml contained in
myfaces-api jarfile. So if *all* jars in the classpath are processed,
the data from myfaces-api.jar will be processed twice.
Options I see are
(a) don't worry; the data will just be identical
(b) check that if a model object is being overwritten, the new data is
identical
(c) have the plugin configured with an explicit list of jars to process
metadata from. Then in the pom it must be configured so that
myfaces-impl is processed and myfaces-api is ignored. Then make it an
error for the same model object to be defined twice.
(d) have a myfaces-metadata.xml file *not* include data inherited from
parent projects. That's cleaner in a way, but means that when processing
other goals we cannot just load the metadata file from the local project
but need to merge in all the ancestor projects too. Ecch.
(e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
they came from.
Option (c) is probably the safest..and not too complicated.
[2] eg something that executes a velocity template against the model
Regards,
Simon