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
