Hi! -------- Original-Nachricht -------- > Datum: Mon, 30 Mar 2009 09:36:22 +0200 > Von: Thomas Neustupny <[email protected]> > An: [email protected] > Betreff: Re: [argouml-dev] Extend CodeGenerator interface to let module find > it\'s classes?
> 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). As I already mentioned, the user can still override the results when the modules were queried what code they could generate. I think, the module author should know best, for what ModelElements his module could generate code, or not. The current decision, just based on the language, is not sufficient anyway. There are already modules, that could only generate code for a specific kind of ModelElement (like StateChart) or classes (the DB module as an example, that should only generate code for tables or views, but not necessarily for other classes). > 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. That's why I thought the decision what classes should be handled belongs to the module. It gives future module authors a lot more freedom to decide, what model elements they want to handle. The current concept cannot handle more complex situations, where a module might depend on some specific information in the model element. As an alternative, the CG dialog would have to be adapted to new modules, which is impossible if the module is proprietary and we don't know of it's existence. --<snip>-- > 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 There might be CG modules, whe don't know about. And there might be constraints, we are not aware of. Think of a specific DB module, that only wants to generate code, if certain conditions are met, like Oracle-specific types or stores procedure are used in the model, or so. We cannot handle all those cases in the CG UI. > - 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? Yup! I still propose to connect the CG UI to the module and let the user override the modules proposals... :-) 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=1480098 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]]
