Created attachment 54453 [details] [review]
Fixes the UML sheet, class.c and UML.c to support templates from the sheet

While testing this fix, I found a bunch of gliphs beening dropped on the
diagram as well as difficulty in drawing the template icon correctly. This was
due to an sync-up failure when I implemented the previous change to class.c. 
Also at Lars' suggestion I have converted my function documentation to use
Javadoc format (at least I tried to follow the guidelines from the sun website)

Thanks for looking into this, it's been annoying me for a while.  I don't think
that adding a new type for template class is the right thing to do, as that
means there's two different classes that implement exactly the same
functionality.  Instead, we should fix the broken intdata field in the sheets
(if you look at UML.sheet.in, you'll see the difference between normal and
templated class being whether its intdata field is 0 or 1).  The rest of the
patch looks great. and I'll see if I can apply some of it.

Thanks for looking into this, it's been annoying me for a while.  I don't think
that adding a new type for template class is the right thing to do, as that
means there's two different classes that implement exactly the same
functionality.  Instead, we should fix the broken intdata field in the sheets
(if you look at UML.sheet.in, you'll see the difference between normal and
templated class being whether its intdata field is 0 or 1).  The rest of the
patch looks great. and I'll see if I can apply some of it.

Applied all but the template class stuff, and template rendering is indeed much
better.  And thank you for the nice function documentation, it is a joy to see.

Sorry to have to disagree with you. I had looked into the intdata field. I use 
this field in the umlclass to select the correct initialization parameters for 
the class being built.
I had found that the root cause of the problem with creating a template class 
was not because the template attribute of the UMLClass was set wrong. It was 
being set correctly in umlclass_create. What was happening was that when the 
function dia_object_default was called to get the default values for the newly 
create object, it would match the type, umlclass_type, and would return a 
default object of type umlclass_type which always had the template attribute 
set to false. What was needed was a unique default object, like the 
umlclass_type but with the template defaulted to true.
Take a look at line 267 in lib/object_defaults.c, function 
dia_object_default_create. You notice that before actually creating the 
object, the function dia_object_default_get is called. This function tries to 
find a default object using the object name "UML - Class". If one does not 
exist, it creates one using the default user data from the type descriptor. 
For UML - Class the intdata for that object is always 0, which indicates a non-
template version of the class. 
After getting the default object, the function dia_object_default_create calls 
the objects create function and then does a copy props using the default 
object as the source of the properties. The end result is reguardless of what 
is set in the building of the actual object, the values in the default object 
overrides it. 
This has two really important implications.
1. The value of intdata can not be used to set a common property which may be 
different from the default. It will be over written.
2. If two object differ only in their default common property values, they 
must have their own unique types.
It is apparent that the use of intdata is an artifact of the way things worked 
before the properties were made common.
Finally, I am of the opinion that in the case of UML, there are many meta 
elements that are derived from a single meta base class. In which case it 
would be rather simple to implement these meta classes by making them 
generalization of the umlclass_type like I have done with 
umlclass_template_type.

I suggest you apply the entire patch.

Hah, we crossed comments on this, basically agreeing (but you in more detail).

Yes, there's a serious mismatch between the defaults system and the intdata (and
stringdata, floatdata etc) system.  Other objects have the same problem (see the
GRAFCET sheet for an extreme example).

It would be nice if these objects with different intdata had different defaults,
one could perhaps do some naming hack in the defaults by using "UML - Class
<intdata=1>" for a name for the template class.  Then each object in the sheet
will automatically have its own defaults.  However, it still leaves the class
name exactly the same, which will show up in default dialog, properties dialog,
selection info in statusbar, 

It may be that it's just me who wants to have each object in a sheet box
correspond to a unique type and that users are fine with the fact that e.g. a
bunch of GRAFCET objects that can be created different can later be turned into
the same, i.e. that the sheet box can contain shortcuts to different
instantiations of the same.  This could be useful for allowing non-coders to
define variations, e.g. defining a sheet entry for Class with an operation
already filled in.  If we loosen the defaults definition to where the same type
can have multiple instances in the sheets, each with its own defaults, we can
allow this both via intdata and possibly later by in-program user definitions.

Seems to me the intdata interface is clunky, though.  It ought to look more like
<param type="boolean" name="isTemplate">true</param> and then the object should
receive a map of these values.  That would avoid a couple nasty hacks around. 
Not for this release, though.

Since you agree should I assume that you will finish applying the patch?

With the properties implemented the way the currently are implemented, the 
intdata feature just can't work at all. Even changing them to use a <param /> 
approach won't work since the default properties of the base class will always 
overwrite the settings made in the "create" function. The entire properties 
approach would have to be redesigned to allow either approach to work the way 
they currently are implemented. 
On the other hand, the whole idea of shape shifting objects may just be the 
wrong approach, and object should not be allowed to simply change shape just 
because of a single parameter?

I agree that the intdata feature is most likely dead.  However, it seems
promising to let the same thing be taken over by object defaults in some way.

The shape shifting objects is just a matter of degree.  Either we insist that
each object in the sheets has its own type, or we allow multiple copies of the
same type with different names, icons and defaults.  I think the latter has more
promise, as it would also allow things like the user turning an object in a
diagram into a sheet object, merely saying that new objects created from that
should have the diagram object's properties as default (note that this is
different from shapes, as functionality is preserved).

2006-01-21  Hans Breuer  <hans@breuer.org>

	* lib/object_defaults.c : pass is_default=TRUE to object_copy_props
	  lib/proplist.c : fixed pdtpp_default()
	  lib/propobject.c : correctly reflect is_default 
	* object/UML/class.c : correct setting of PROP_FLAG_NO_DEFAULTS and
	PROP_FLAG_DONT_MERGE. With the above this fixes bug #320934