Hi Chad, What you can do in the second use-case is check for parameters using a decision point in the activity graph and redirect to another use-case in case they are missing (seems to be the cleanest solution since a use-case could be called from anywhere.. also without parameters)
What concerns the first use-case then, since all parameters are simply in request scope you can model them on a transition going into a final state .. however, the trick (for me) will be to have these parameters available in the target use-case action form For now I did not implement this yet and I always have been using request.setAttribute() in the first and getAttribute() in the second use-case, the reason was that until recently we had one form in the session per use-case Fortunately, with the recent major change (currently only in CVS and not yet fully working), it will be possible to nicely expose all fields in the action forms even across actions, this is one of the benefits of having a single form per action in request scope (as was the case in the very beginning of the cartridge) Just to make sure, can you create a JIRA issue for it so I won't forget ? Thanks -- Wouter > -----Original Message----- > From: Chad Brandon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 3:21 AM > To: [EMAIL PROTECTED] > Subject: passing data between use cases > > Hey dude, > > How do we model parameters so that they are passed between use cases? > > thanks man, > > Chad ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
