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 <[EMAIL PROTECTED]> 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 <[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 > > > >
