myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe" <lu4...@gmail.com>
Subject Re: MyfacesBuilderPlugin
Date Thu, 03 Apr 2008 23:50:19 GMT
On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <kmann@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 <lu4242@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
>
>
>

Mime
View raw message