[EMAIL PROTECTED] wrote:
Quote: I found the problem and it made appear that the implementation of this javadoc improvement is going to be far more difficult than I thought because there are plenty of tests that are going to fail. (end of quote) well, that's the purpose, right ? for every cartridge the tests are going to fail because the code generation process is going to add javadoc for parameters where possible .. don't forget to add a test for this in each cartridge where a template has changed (end of quote) Sure I'll do. [EMAIL PROTECTED] wrote: Quote: Actually I was even thinking that theoretically, the best would be to override getDocumentation() in the different subclasses of ModelElementFacade, including ParameterFacade. (end of quote) no, because the reason you're overrriding in the PIM (uml metafacade) layer is because you want some specific PSM (javadoc) thing rendered I think the best way to proceed is to add a method to the StringUtilsHelper class, and this method can be completely JavaDoc aware and performing all your required logic .. you would then call this method from the templates (not the facades) as the templates are in the PSM layer anyway this is an easy and clean solution to your problem since it only affects the templates, I would avoid putting a Javadoc documentation generator in the uml metafacades because it's too close to the Java platform (in other words: during code generation for .Net it would be entirely useless) what do you think ? (end of quote) I get your point about PIM/PSM separation. So I see another solution. Forgive me if it implies another class creation instead of reusing some existing one but I think documentation generation deserves a class of its own. Actually, it can be interesting to generate documentation for other documentation systems like doxygen for example. So why not define a base interface named DocumentationGenerator with method like getClassifierDocumentation, getMethodDocumentation, getParameterDocumentation and so one, and then a JavaDocGenerator that would implement this interface and called from the templates. That way, we would not have to modify getDocumentation and all the templates that still use this method would not make the tests fail. And we would keep documentation generation in one place in order to be able to update it (e.g. as javadoc specification evolves) or extend it (e.g. with a doxygen generator). I know it might seem a bit "too much" but I think it would be a really interesting feature, to be able to edit documentation in the UML model, without caring about the syntax of a particular documentation system. What do you think ? -- Sébastien Arbogast _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=2066#2066 Posting to http://forum.andromda.org/ is preferred over posting to the mailing list! ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Andromda-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-user
