Hi folks, this is really good: Finally, some traffic and lively discussions on the mailing list again! :-)
Keep on disagreeing - it will push the limits of AndroMDA. :-) Now for the subject itself: Why don't we enhance the interface of a cartridge and let it add objects to the Velocity context by itself? The core would say cartridge.addContextObjects (velocityContext); and bingo: the cartridge can do what it wants to do. The question is: when do we do this? Cheers, Matthias B. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Matthias David > Sent: Tuesday, May 27, 2003 7:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: AW: [Andromda-devel] ScriptHelper subtask > > > Hi Tony, > > you're right that's kind of a solution. I thought about that, > too. But this solution means that you have to add these new > helpers to the default helper (or to any other > project-default helper). So you have to write two new classes > instead of one! What if I want to use Andromda's > DefaultHelper and a cartridge-specific one at the same time? > With your solution I still have to subclass the default > helper to add the new one. > > Your turn! > > Matthias. > > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 27. Mai 2003 20:05 > An: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Betreff: RE: [Andromda-devel] ScriptHelper subtask > > > Hi, > > I guess I will disagree back at you :-) > > You are not restricted to a single helper with the current > design, because you could add as many methods as you want to > the one helper that would give you access to other helpers. > > Example: > > $transform.workflowHelper > $transform.stateMachineHelper > $transform.useCaseHelper > > > >-- Original Message -- > >From: [EMAIL PROTECTED] > >To: "Anthony Mowers" <[EMAIL PROTECTED]> > >Cc: [EMAIL PROTECTED] > >Subject: RE: [Andromda-devel] ScriptHelper subtask > >Date: Tue, 27 May 2003 10:26:20 +0200 (MEST) > > > > > >Hi Anthony, > > > >I don't agree with you. I know that andromda allows the > definition of a > > >single helper class on a per-template basis. But this still restricts > >andromda to the single "$transform" helper. > >Why shouldn't I use different helper on one template? I think the > existence > >of the StringUtilsHelper proofs that it can make sense to have > different > >helper classes for different purposes. Even within one template. > >Another problem with the current design is that I have to > subclass the > >default helper SimpleOOHelper or UMLDefaultHelper if I want > to use the > default > >helper methods AND my own helper methods within one template. In case > >my own helper methods do not address the static behavior of > the model > >the design results in a helper that mixes different aspects of the > >model in one class. So in > >my opinion subclassing is not the proper design here. > >What do you think? > > > >Matthias. > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: ObjectStore. > >If flattening out C++ or Java code to make your application fit in a > >relational database is painful, don't do it! Check out > ObjectStore. Now > > >part of Progress Software. http://www.objectstore.net/sourceforge > >_______________________________________________ > >Andromda-devel mailing list [EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/andromda-devel > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application > fit in a relational database is painful, don't do it! Check > out ObjectStore. Now part of Progress Software. > http://www.objectstore.net/sourceforge > > _______________________________________________ > Andromda-devel mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/andromda-devel > > ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
