Matthias Bohlen wrote:
Hi, Wouter,true
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 thetrue
action state
true* 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:yes, perfectly
* Did I understand this correctly?
that's 3/3, my best student so far :-)
* How do we link the view class to the action state, especially in the situation when it has no dependency to the form class?
Now that you mention it I am reconsidering what I originally had in mind. There are some points to take into account when writing Struts code, I will try to explain below; but nevertheless, UML profiles should be designed without any implementation in mind (Struts, Swing, ...)
It seems we have two ways to proceed:
1. using a DispatchAction per use-case (as we do now)
personally I like how dispatch actions allow you to group
actions that logically belong together, that's what they are
designed for (such as inside a use-case)
* drawback: we can only use a single form per dispatch
action, this means reusing the form for each action
state, doing otherwise would result in jumping through hoops
* advantage: simpler struts-config.xml, easier to work
with the classes
2. using a different Action per action state
* drawback: generates more classes, bigger
struts-config.xml, need to model a controller class for
each action state
* advantage: it is possible to have a form dedicated to
the specific action (View class --> Action State)
for the sake of simplicity, let me explain what I have in mind as a good solution
I considered (2) as the way to go but this would really impose tedious tasks onto the poor user who just wants something done in no-time, eg. for each action state he would need to model a separate controller class and a form bean, as the model changes often this can easily become a boring task
So I would stick with (1) and keep working with the dispatch actions. the thing to solve here is that a dispatch action has a single action mapping entry in struts-config.xml, so also only one form is known to the dispatch action's methods, but how do we know which fields of the form should make up the <form> fields in the generated JSP ? Well we could do this:
The dynamic model remains the same
The static model is changed. The controller form may still have
attributes but it may be left empty too. Optionally the user
adds dependend classes to this form class, these classes have
attributes and a tagged value linking them to an action state (1
class <--> 1 action state). We model the dependend classes as if
they are child classes of the (abstract) controller form,
inheriting any attributes from it. This way the generated code would still use 1 single form bean
in which all the fields are merged together, but the JSPs would
only render the form fields associated to the attributes of the
classes linked with the tagged value. As you see the mapping Struts-UML is not one-on-one like this,
because in the Struts implementation you would have 1 form bean
while in fact you model more than one, possible one per action
state.I think this is a viable solution because the UML is clean and the static and dynamic models feel very natural, furthermore the Struts implementation is not jumping through hoops to get the job done.
voila, that's it ... can you let me know what you think ? any questions ?
regards Wouter.
only the static model gets something extra. Optionally the user is allowed to add a dependency (or association, I don't know what is suited best) from a new class to the controller form, let's call this the view class
------------------------------------------------------- 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
