On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > *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 <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> 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 > > >
