Great!

By the way, you're right, I should sign my mails with "Matthias D." ;-))

-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 27. Mai 2003 21:53
An: Matthias David; [EMAIL PROTECTED]
Betreff: 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

Reply via email to