Hi Thomas, I think you've hit the nail on the head when it comes to what's been confusing me about the "Generate Code for Project" functionality. There are basically three expected steps:
1. Select the classes that you want (either the entire project, or some subset of the project (all classes in a diagram, all classes in a package (or package subtree)). 2. Select the output language 3. Select the output directory I think all 3 of those steps could probably fit on a single dialog, and would make it easier for users to generate code. I agree that persisting the output language and output directory would definitely make it easier for people. I wonder if it's possible to infer the default language from the language what the user currently has selected in the Source tab? So if the user currently has the Java selected, it would default to the Java generator. Mark On Mon, Sep 5, 2011 at 10:17 AM, Thomas Neustupny <[email protected]> wrote: > Hi, > > it's in the Generation menu, the second group of menu items. > > It was added some ten years ago (by me) and works well, but unfortunately > it's almost impossible to figure how to use it. So I added in my local > sources a label in the "Settings for Generate for Project..." dialog that > states: > > - Use the "Set Source Path..." option in the model tree to add items. > > I wonder if this would help? > > The term "Generate for project" is really bad. But the idea is simple: > while F7 generates code from the current diagram, "Generate Code for > Project" generates code directly from the model without the detour via a > diagram. So maybe it would be better to speak of "Generate code from > diagram" vs. "Generate code from model". > > The user needs a way to control which classes are used for code generation > and which not. With the F7 approach, one has a diagram with everything in > the model for which code is to be generated. Since model elements can occur > on more than one diagram, it is possible to easily organize what is > generated (and for which language). "Generate for Project" has the > advantages that the destination path is persisted, and one setting for a > namespace is sufficient to generate all in the whole subtree. > > Maybe it's better to drop the "Generate for Project" feature and find a > better way to persist the destination path? > > Also one could persist which language is to be generated, for there could > be both e.g. Java code and SQL statements generated for one project, or > whatever code generator is added. > > Anyway, I suggest to keep it simple and do the more sophisticated things > with MDA or a (whoever develops it) template based code generator. > > Thomas > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > ------------------------------------------------------ > > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2835644 > > To unsubscribe from this discussion, e-mail: [ > [email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2835652 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
