AW: AW: [Andromda-devel] ScriptHelper subtask

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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=FCngliche Nachricht-----
Von: Matthias Bohlen [mailto:inf...@mb...]=20
Gesendet: Dienstag, 27. Mai 2003 22:33
An: to...@am...; 'Matthias David';
and...@li...
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:

What do you think?
Matthias B.

> -----Original Message-----
> From: and...@li...
> [mailto:and...@li...] On Behalf=20
> Of to...@am...
> Sent: Tuesday, May 27, 2003 8:53 PM
> To: Matthias David; and...@li...
> Subject: RE: AW: [Andromda-devel] ScriptHelper subtask
>=20
>=20
>=20
> I like this idea that you have proposed.
>=20
> But I was confused by which 'Matthias' actually proposed it :-)
>=20
> >-- Original Message --
> >From: "Matthias David" <Mat...@gm...>
> >To: <and...@li...>
> >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=20
> >helpers. Therefore it's up to the cartridge developer to ensure that=20
> >the right helper class is in place. There's no need to=20
> 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=3D"WebForm"
> >    sheet=3D"templates/StrutsForm.vsl"
> >    outputPattern=3D"{0}/{1}.java"
> >    outlet=3D"forms"
> >    overWrite=3D"true"
> >    helperClass=3D"org.xyz.MyHelper"
> >  />
> >
> >and
> >
> >$MyHelper.someMethod()
> >
> >Or
> >
> ><cartridge name=3D"struts">
> >  ...
> >  <helperClass name=3D"myHelper" class=3D"org.xyz.MyHelper"/>
> >  ...
> ></cartdige>
> >
> >and
> >
> >$myHelper
> >
> >
> >Matthias.
> >
> >-----Urspr=FCngliche Nachricht-----
> >Von: Matthias Bohlen [mailto:inf...@mb...]
> >Gesendet: Dienstag, 27. Mai 2003 20:28
> >An: 'Matthias David'; to...@am...
> >Cc: and...@li...
> >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: and...@li...
> >> [mailto:and...@li...] On Behalf Of=20
> >> Matthias David
> >> Sent: Tuesday, May 27, 2003 7:17 PM
> >> To: to...@am...
> >> Cc: and...@li...
> >> Subject: AW: [Andromda-devel] ScriptHelper subtask
> >>=20
> >>=20
> >> Hi Tony,
> >>=20
> >> 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=20
> 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=20
> >> time? With your solution I still have to subclass the default
> >> helper to add the new one.
> >>=20
> >> Your turn!
> >>=20
> >> Matthias.
> >>=20
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: to...@am... [mailto:to...@am...]
> >> Gesendet: Dienstag, 27. Mai 2003 20:05
> >> An: Mat...@gm...
> >> Cc: and...@li...
> >> Betreff: RE: [Andromda-devel] ScriptHelper subtask
> >>=20
> >>=20
> >> Hi,
> >>=20
> >> I guess I will disagree back at you :-)
> >>=20
> >> You are not restricted to a single helper with the current design,
> >> because you could add as many methods as you want to the=20
> one helper
> >> that would give you access to other helpers.
> >>=20
> >> Example:
> >>=20
> >>  $transform.workflowHelper
> >>  $transform.stateMachineHelper
> >>  $transform.useCaseHelper
> >>=20
> >>=20
> >> >-- Original Message --
> >> >From: Mat...@gm...
> >> >To: "Anthony Mowers" <to...@am...>
> >> >Cc: and...@li...
> >> >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
> >>=20
> >> >single helper class on a per-template basis. But this still
> >> >restricts
> >
> >> >andromda to the single "$transform" helper. Why shouldn't I use=20
> >> >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
>=20
> >> >relational database is painful, don't do it! Check out
> >> ObjectStore. Now
> >>=20
> >> >part of Progress Software. http://www.objectstore.net/sourceforge
> >> >_______________________________________________
> >> >Andromda-devel mailing list And...@li...
> >> >https://lists.sourceforge.net/lists/listinfo/andromda-devel
> >>=20
> >>=20
> >>=20
> >>=20
> >> -------------------------------------------------------
> >> 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
> >>=20
> >>=20
> _______________________________________________
> >> Andromda-devel mailing list And...@li...
> >> https://lists.sourceforge.net/lists/listinfo/andromda-devel
> >>=20
> >>=20
> >
> >
> >
> >
> >-------------------------------------------------------
> >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=20
> ObjectStore. Now
> >part of Progress Software. http://www.objectstore.net/sourceforge
> >_______________________________________________
> >Andromda-devel mailing list And...@li...
> >https://lists.sourceforge.net/lists/listinfo/andromda-devel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=20
> out ObjectStore. Now part of Progress Software.=20
> http://www.objectstore.net/sourceforge
>=20
> _______________________________________________
> Andromda-devel mailing list And...@li...
> https://lists.sourceforge.net/lists/listinfo/andromda-devel
>=20
>=20

AW: AW: [Andromda-devel] ScriptHelper subtask

Easily turn UML models into code

AW: AW: [Andromda-devel] ScriptHelper subtask