> I created a new action state's tagged value "@andromda.struts.form.name", > and all the action states with the same value (in that use case) will be > created in the same jsp, merging the fields, enabling/disabling the fields > as needed and so on. This way the modeler can model the activity > "normally" and the CRUD nature can be added later. What do you think ? >
yes, I can see this works and this feature was more or less easier to implement using the previous bpm4struts version but I still think there is good reason not to provide it by default, mainly because it goes against the concept of modelling different actions, because that's what it is: you model different use-cases with only a single one, after that you make some assumptions about its context (CRUD) and generate more than just one use-case. Feel free to implement it as you wish, but personally I would model all use-cases, no matter what. In fact, my CRUD use-cases are not similar at all, they really depend on the exact location in the application. This way I have more control over the flow into other use-cases etc... > One question: does the StrutsUseCase.getPages() method returns just the > pages of that use case ? > I created a new template and the following code: > yes this is true, I see you point, I will refactor this (hopefully) today... this method will be renamed to 'getAllPages' and the one you want will be called 'getPages' the reason is that both the FrontEndApplication and FrontEndUseCase stereotypes are put on use-cases, this means I need the sum of all features in the same fa�ade so basically I will follow this convention: if it has 'all' in the name it is for the FrontEndApplication, otherwise it is for the FrontEndUseCase Wouter. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
