I think this would be a good solution for now. The XML version could be added later if it turns out that this feature is used very often. But I would change the signature of your suggested method to "IAndroMDACartdridge.addContextObjects(Map context)". Just to decouple the Interface from Velocity. This would be useful in case that Andromda should support different template engines some day. (By the way: Has this been discussed before?)
Matthias D. -----Urspr�ngliche Nachricht----- Von: Matthias Bohlen [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 27. Mai 2003 22:33 An: [EMAIL PROTECTED]; 'Matthias David'; [EMAIL PROTECTED] Betreff: RE: AW: [Andromda-devel] ScriptHelper subtask Hmmmm... Doing it in Java instead of XML would be better (at least I think so). A cartridge could add different kinds of objects to the context and (the main advantage) could initialize each of them with a state. The change I proposed IAndroMDACartridge.addContextObjects (VelocityContext ve) would be made in the IAndroMDACartridge interface and in the DefaultAndroMDACartridge class. A cartridge could then provide its own cartridge class that implements IAndroMDACartridge. A cartridge developer would configure this using the already existing <class> tag: <cartridge name="bla"> <class name="org.xyz.MyCartridge" /> ... </cartridge> What do you think? Matthias B. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of [EMAIL PROTECTED] > Sent: Tuesday, May 27, 2003 8:53 PM > To: Matthias David; [EMAIL PROTECTED] > Subject: RE: AW: [Andromda-devel] ScriptHelper subtask > > > > I like this idea that you have proposed. > > But I was confused by which 'Matthias' actually proposed it :-) > > >-- Original Message -- > >From: "Matthias David" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Subject: AW: [Andromda-devel] ScriptHelper subtask > >Date: Tue, 27 May 2003 21:06:46 +0200 > > > > > >Hi Matthias, > > > >I think the best place to add context objects would be the cartridge > >descriptor because the associated templates need these additional > >helpers. Therefore it's up to the cartridge developer to ensure that > >the right helper class is in place. There's no need to > define a helper > >within the buildfile (so my first idea with the <helperClass> tag on > >this was not really well thought out ;-)) Anyway, what about this > > > > <template > > stereotype="WebForm" > > sheet="templates/StrutsForm.vsl" > > outputPattern="{0}/{1}.java" > > outlet="forms" > > overWrite="true" > > helperClass="org.xyz.MyHelper" > > /> > > > >and > > > >$MyHelper.someMethod() > > > >Or > > > ><cartridge name="struts"> > > ... > > <helperClass name="myHelper" class="org.xyz.MyHelper"/> > > ... > ></cartdige> > > > >and > > > >$myHelper > > > > > >Matthias. > > > >-----Urspr�ngliche Nachricht----- > >Von: Matthias Bohlen [mailto:[EMAIL PROTECTED] > >Gesendet: Dienstag, 27. Mai 2003 20:28 > >An: 'Matthias David'; [EMAIL PROTECTED] > >Cc: [EMAIL PROTECTED] > >Betreff: RE: [Andromda-devel] ScriptHelper subtask > > > > > >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 > > > > > ------------------------------------------------------- > 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
