[EMAIL PROTECTED] wrote: how does emitting documentation into an arbitrary format relate to your requirement to have it working differently for different facades ? (end of quote)
OK you're right. Back to the roots, before I took off. My need : I want to be able to edit documentation in the GUI of my model editor and I want this documentation to be translated into any documentation comment syntax I can use, especially javadoc. For the moment, documentation for classes and methods is generated thanks to the ModelElementFacade.getDocumentation() method. Right ? Well the problem with that method is that it can generate documentation, and even javadoc-compliant documentation for classes, methods and attributes, but in order to document parameters, I need to add a few information items like the parameter name and the parameter tag. Furthermore, in javadoc, parameter documentation is included inside method documentation, which the current implementation of getDocumentation() doesn't allow me to do. So I first tried to modify the implementation of this method to make that possible but it made appear two major problems : 1 - all the tests that generate documentation and use that method are going to fail 2 - we can't modify the current implementation without overloading getDocumentation to add at least one parameter, which greatly endangers the separation of PIM and PSM layers As you made me realize, documentation generation should only be part of PSM part, so its logic shouldn't appear in MetaFacades, or at least not further than the current getDocumentation. So the best way is to externalize that in a helper class that would be made available to velocity templates. But then I asked myself, if parameters are a particular case, maybe there are others, or there can be others in the future. And that's why I created the DocumentationGenerator interface with its first JavadocGenerator implementation. For now the interface has 4 methods : public String getClassifierDocumentation(ClassifierFacade classifierFacade); public String getAttributeFacade(AttributeFacade attributeFacade); public String getOperationFacade(OperationFacade operationFacade); public String getParameterFacade(ParameterFacade); And in the javadoc implementation for example, the 1st and 2nd methods are almost the same as the getDocumentation for now. And the third one calls the 4th one for each of its parameters. So now we're back to your question : [EMAIL PROTECTED] wrote: how does emitting documentation into an arbitrary format relate to your requirement to have it working differently for different facades ? (end of quote) For now, the goal is to take the parameter specificity into account while making the documentation generation process more extensible and evolutive for the future. Did I answer ? -- Sébastien Arbogast _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=2089#2089 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 Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
