From: Carlos Cuenca [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004
5:32 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Andromda-user] Re:
[Andromda-devel] preload data for editing
Ok.. sorry,
here I go again...
In the deferred operation of Action State A, (deferredOpA), it should be
necesary to have access to both the page Variables of the outgoing transition
(when this transition goes to a FrontEndView, FrontEndViewB) and also to all
the action parameters going out from this FrontEndView. (in the example, just
the parameters of methodB)
[WZ> ] my reasoning behind the operation arguments was
not to have them represent actual ‘arguments’ as we know them in
Java, but simply anything that is needed or created in the operation, AFAIK
nothing in UML prohibits me from working this way
My reason is: I can underestand that in both Action State A and Action State B
deferred operations, it is needed to determine which action parameters are
comming in (since there might be possible more than one incoming actions) so
you need to determine them on the operation signature.
But as for sure there is just one outgoing action, so you can make accesible
both the pageVariables and action parameters of the outgoing transitions in
order to not need to write on the arguments of the operation.
[WZ> ] and what in case there are two outgoing
transitions ? how should the cartridge behave in that case ? also, suppose the
transition is looping the action state into a cycle … there are many
possiblities that could get us into trouble like this; until now I simply
played it safe and did not try to exploit any side-effects (such as having only
1 outgoing transition)
And I would like to have access to this parameters becasuse if I am editing a
record on FrontEndViewB, I want to preload the data that goes within the parameterA
on methodB.
[WZ> ] for now you’ll have to model it in the
operation too I’m afraid .. this is very stric UML I know, but I’m
afraid to break functionality by touching those things .. we’re planning
a release for next week so I prefer to keep things as they are right now. What
you can do is go through all the possiblities and try to get things running yourself
… that is what I did, I’m now a little reluctant to again change
the implementation
Carlos
[WZ> ] thanks for the attached image … very useful J