[Uml-devel] Code generation: progress and a question about decodeClip5 function in umldrag.cpp

[Jonathan Riddell]

On Wed, Jul 23, 2003 at 11:49:35AM -0400, Brian Thomas wrote:

> 	Its been about a month, but I have been quite busy hacking away at
> 	the code generation system. At this point, I have the basics of the
> 	system created, code documents are now tied to the UMLDocument,
> 	and any parent objects they belong to (for example, UMLClassifiers)
> 	so that they are automatically updated when the parent object is changed.

Excellent.

> 	Having this functionality allows me to "re-use" the existing GUI interface so that,
> 	for example, when an attribute or operation is added to a class, the slot
> 	"syncToParent" is called for the appropriate codedocuments, and their
> 	code updated/re-generated. I hope to have an updated XMI document
> 	and a tarball of the code (rather than a CVS update at this time since
> 	my code only has the Java working right now) for inspection by those in
> 	the group who are interested.

A tarball would be good.

> 	One question I have is that I decided to change the constructor of the UMLoperation
> 	class so that it requires a UMLClassifier parent object. This makes sense
> 	(to me) as operations may only belong to classifiers (which you will recall are
> 	interfaces or actual classes). The problem with making this change is that 
> 	there is a function in umldrag.cpp that tries to instanciate UMLOperations from
> 	the document rather than the parent classifier. It would appear to me that it
> 	is there so that the user may "drag" operations from one class to another, but
> 	I am not sure. Can someone fill me in on what the function decodeClip5 does?

decodeClip5 is for pasteing attributes/operations/templates from the
tree view.

UMLDoc::makeNewClassifierObject() does seem to make the umldoc the
parent which is possibly not the ideal way to do it.  You could see if
it's possible to find the new parent UMLClassifier and make that the
parent or you could just leave it as it is and hope for the best (is
there are requirement to change the UMLOperation constructor or would
it just be neater?).

Jonathan Riddell