Thoughts on the UMLWidgets/FloatingText inheritance (or lack of) Was: Re: [Uml-devel] kdesdk/umbrello/umbrello/dialogs

[Brian Thomas]

On Thursday 25 September 2003 03:00 pm, Oliver Kellogg wrote:
> > I dont think we need to have a
> > localID at all, and I dont see a need (currently) for the umlwidget to be
> > storing object id's as thier id's unless they are 'objectwidgets'. So
> > perhaps the object widget class is the class that has an 'objectID' field
> > (and remove terrible localID).
>
> Agreed for the case of "thick" widgets, i.e. widgets that have a
> UML counterpart.
> OTOH something like the NoteWidget (which does not have the UML
> counterpart) probably needs the ID, else we couldn't tell different
> NoteWidgets apart.

	Well, I still think we need 'widgetId' in all cases. Its just that *sometimes*
	the object id is also needed, and in those cases, we need to create a 
	subclass of umlwidget. Perhaps an abstract class called 'umlwidgetwithobject'
	that may be inherted in..e.g. a 'brief tree of inheritance might look like:

         umlWidget (has basic fields like widgetId)
              /\
               |
               |
       assocationWidget                   ownedByUMLObject (adds objectId)
               /\    (adds assocList)                  /\
                |                                                      |
                ---------------------------------------------
                                           |
                    ownedFloatTextWidget (adds text field)

	The ownedFloatTextWidget would multiply inhert from both 'floatingTextWidget' and
	'ownedByUMLObject'. The 'associationWidget' (the old 'floatingTextWidget' used
	in associations) would add in fields for association lists. While Im here, I think the 
	'widgetType' id's (like wt_Text) suck too. Each id really means its a different class (or
	should be) especially if there are fields in umlwidget (like the association list) which are
	only used for some of the types of widget.

	Well, having said all that, I wouldnt want to see a code-rewrite of this nature right now.
	The code base is unstable enough as is, we should wait to change the structure of the 
	widgets after KDE 3.2 comes out.


					-b.t.