Hi Andreas, are you sure that the module can always decide if an element is to be generated by it? If not, then I think it would be better to let the user decide which elements should be generated by which module. This decision should be persisted in the project, or in the model (e.g. by stereotypes/tags).
What I'm worried aubout is, that your interface would reach it's limit e.g. when there are classes that are modeled in a similar way but should be handled differently w.r.t. CG. Then, We'd search for another concept, which would be the third or fourth for CG. I'm aiming for one continuous complete concept for controling CG for many model artifacts and different CG modules at once. Years ago I introduced a logic based on a custom tag definition 'src_path' to select which elements should be generated (by 'Generation->Generate Code for Project...'). It's not optimal because: - it doesn't take into account different target languages - tagged values should better belong to stereotypes (ok, back then we had only one stereotype for each model element...) I'd vote for a replacement of this that also fulfills your requirements. A solution that let's the user decide, not the module (which only should react on nonsense settings). This would also not need a new/changed interface. An initial idea: (maybe you have a better one) We introduce a stereotype <<CG>> that applies to single model elements, but also to namespaces to control CG for everything that's included. Outer <<CG>> setting are overridden by inner <<CG>> settings, in the same way it is done now for the 'src_path' tagged values. So it's simple, because the logic is there already. The stereotype has the following TD: - 'src_path': same function as the existing 'src_path' today - 'src_language' for the target language (1..*) Persistence: it's all in the model. GUI: existing handling for stereotypes and tagged values is sufficient in a first step, we only need to update the dialog 'Generation->Settings for Generate for Project...'. Later, I'd suggest to enhance the controls to make the settings: - suggest possible values for 'src_language' (combobox) based on the existing CG modules - quickly make CG settings in the explorer (like it is done now for 'src_path' (You see that we already have many things in place, it only needs to be updated.) What do you think? Is there still a need for your suggested interface that I overlooked? Thomas -------- Original-Nachricht -------- > Datum: Fri, 27 Mar 2009 17:23:37 +0100 > Von: Andreas Rueckert <[email protected]> > An: [email protected] > Betreff: Re: [argouml-dev] Extend CodeGenerator interface to let module find > it\'s classes? > Hi! > > -------- Original-Nachricht -------- > > Datum: Fri, 27 Mar 2009 08:43:52 -0400 > > Von: Tom Morris <[email protected]> > > An: [email protected] > > Betreff: Re: [argouml-dev] Extend CodeGenerator interface to let module > find it\'s classes? > > --<snip>-- > > > Couldn't this be implemented as an option internal to the module > > itself? Then the user could say "generate all classes" and the module > > could filter those that it knows how to generate. > > Not in any cases. In case of the SQL module, we could enforce the use of > the DB profile > and ignore classes without a 'Table' stereotype as an example. But in some > cases there might > be good reasons not to use a stereotype (there could be classes that are > actually tables _and_ > Java classes as example). In other cases, it's not necessary clear from > the diagram if someone > wants to create Java, C++ or maybe PHP from a class? > > --<snip>-- > > > > If it did turn out to be something requiring an API change, there are > > ways to do it without breaking existing modules. Something which > > broke all existing modules would be very bad. > > I know...that's why I posted here before committing any modifications... > :-) > > Ciao, > Andreas > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger01 > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1445624 > > 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]] -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1479077 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]]
