don't worry, most of these methods will have that suffix removed, also a prefix will not be required ...
consider the changes in CVS a mistake (they will compile and all, but it is better for some of these method not to have a suffix or a prefix... I still have to decide)
about these methods, they are not wrapper methods, it is just that I need to call them in the (abstract) parent class but I don't want to implement them there (implementation is a manual process that should not be overwritten by generating)
so basically you need to be aware of this:
* abstract parent class: contains the process flow of the use-case
(and nothing else!) - we change this flow not in this class but in
the UML model (and regenerate the code)
* implementation class: implements the (few) abstract methods
(ObjectFlowStates and choice Pseudostates) - done manually by the userthis means: the user models the flow in UML and implements the delegate calls to the backend in Java, since the places where to implement are generated for you (by means of simple methods in the Impl class, called by the process flow in the parent class) it is easy to see what you still need to do and how (Javadoc is rendered from the UML documentation on the modelelements)
I do use the "Abstract" suffix for classes too, in that case they can be considered as wrappers
HTH Wouter.
Matthias Bohlen wrote:
Hi Wouter,
first of all, what I see from the CVS commit messages, fascinates me. I must say that I find this very cool what you are doing in bpm4struts.
One hint: You generate abstract methods with the suffix "Abstract". I wondered whether this should be changed to use a "handle..." prefix, instead, to be consistent to the hibernate and meta cartridges. I don't know (however) whether you really meant the same concept (wrapper method that wraps abstract method which is implemented in the derived class).
Cheers... Matthias
---
Matthias Bohlen "Consulting that helps project teams to succeed..." http://www.mbohlen.de/
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
