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
