Hi, Wouter, let me see if I understand this part of the UML profile correctly. After your changes, we would have: * an action state without tagged values * a form class that has a tagged value that contains the name of the action state * an (optional) view class that has an attribute for each input field and (optionally) a dependency on the form class that tells the generator to copy the attributes of the form class into the view class.
Questions: * Did I understand this correctly? * How do we link the view class to the action state, especially in the situation when it has no dependency to the form class? Cheers... Matthias > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Wouter Zoons > Sent: Thursday, December 11, 2003 9:36 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: AW: [Andromda-devel] bpm4strus X xdoclets > > > > >A few UML elements, a good generator, and off goes the app in the > >browser > >- this is what I'd like to have in the near future again. > The old struts > >cartridge had JSP views but abused UML. With Wouter's new > cartridge, I'd > >like to achieve the same thing using UML correctly and more > effectively > >than before. > > > > > > > agreed > > > > >BTW, Wouter, I do not think that tagged values are a good > way to model > >input fields in a view. We should use a view class instead > that has the > >input fields as attributes. The view class can then be > associated with > >the action state using a tagged value on that action state > that tells > >the name of the view class. In most cases, the view class will > >duplicate the attributes of the form class - maybe we should > model an > >empty view class that simply has a dependency to the form class. The > >template can then follow the dependency and read the attributes from > >the form class. > > > > > Matthias, > > one of the changes I was thinking about for bpm4struts is to have the > tagged values on the UML classes instead of the state > vertices, so the > classes would references the state vertices and not vice > versa, IMO this > is cleaner since the dynamic model will then be more loosely coupled > from the static model, the static model is closer to the actual > implementation anyway (classnames, methods, etc...) so I have the > feeling it to be more natural this way > > what do you think ? > > Wouter. > > ps: this has a rather serious impact for the user as it is tedious to > enter a lot of tagged values, and that's what the user will > need to do > once we decide to change the tagged values strategy in a > later version > of the cartridge, better to do it asap > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us > help YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Andromda-devel mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/andromda-devel > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
