Maxim, See my comment below ...
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ма > ксим Петрашев > Sent: Friday, June 20, 2003 7:04 AM > To: [EMAIL PROTECTED] > Subject: [Andromda-devel] AndroMDAGenTask and predefined objects > in vsl-templates > > > Right now AndroMDAGenTask pass to velocity engine the following objects: > velocityContext.put("model", context.scriptHelper.getModel()); > velocityContext.put("transform", context.scriptHelper); > velocityContext.put("str", new StringUtilsHelper()); > velocityContext.put("class", modelElement); > velocityContext.put("date", new java.util.Date()); > > (see processModelElementWithOneTemplate) > In andromda-cartridge.xml I can define in > template/@transformClass any class instance of which will create > as $transform-object to velocity engine. In this class I can > override getModel-method and create instance of other my class > for model... But I can't to do this for "str", "class" and "date" objects. > There is a way for you to change the 'class' object in the velocity context to be whatever you want it to be. See: org.andromda.core.uml14.DefaultHelper.getModelElements and compare it with the overridden implementation in: org.andromda.core.simpleuml.SimpleOOHelper.getModelElements I believe SimpleOOHelper is an example of what you are asking for. It produces its own 'wrapped' model element objects with an extended set of methods. The AndroMDA engine then takes whatever objects are returned by the method getModelElements and places them in the velocity context under the 'class' name. Therefore if you want to add more methods to the model element objects you can do this by overriding the SimpleOOHelper.getModelElements and use the cartridge.xml to set the transformClass to your new class. I believe that will do what you want. But .... I do not think extending the model elements is a good way to add the functionality you are talking about. Take a look at the DirectionalAssociationEnd class as an alternative approach. It wraps the AssociationEnd model element, and creates a class with exactly the methods the template needs, no more and no less. This sort of thing is extremely easy to port if for some reason you have to port your templates to run with something other than UML14. It provides pretty much the same functionality that you'd get by extending the model elements, but is simple to understand and port. I wrote the SimpleOOHelper class. It extends the model elements directly. I think it is a poor way of doing things. I implemented it so that UML2EJB templates would work with AndroMDA. On the other hand I did not write the DirectionalAssociationEnd interface, somebody who wrote UML2EJB wrote that interface. I am glad they did. When I had to port the UML2EJB templates to AndroMDA it was the single easiest thing to port. I can't totally explain in a short email why I think extending the model elements directly is a bad approach. All I can say is that I think having your ScriptHelper wrap the model elements, as in something like the DirectionalAssociation class, is a better approach. ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
