[Uml-devel] Re: Uml-devel digest, Vol 1 #499 - 10 msgs

Thu May 15 12:04:03 UTC 2003

On Thursday 15 May 2003 02:37 pm, Jonathan wrote:
> On Wed, 14 May 2003, Brian Thomas wrote:
> >       1. Easy user interface.
> >                B. Allow user to insert specified code in
> > methods/operations with interface.
> >                C. Allow user to preview code to be generated with
> > interface (NOT necessarily EDIT this code however).
>
> B and C seem contradictory to me.  I like C (look, but don't touch) but B
> seems like a bad idea since being able to edit the code brings in a whole
> bunch of problems.

	What sort of problems? Im not talking about being able to edit more
	than the interior body of the operation. You wouldnt be able to edit
	the name of the operation, its parameters, etc. That stuff IS changeable
	using the current interface. I'd simply make the code view "clickable"
	so that the appropriate popup dialog is made available to the user. 
	
	Consider the following  code that is part of a preview:

  // comment
  public Object getMyAttribute ( <void> ) { <body of operation> }

	The whole thing is clickable. Various parts of this code pull up diffeent
	popups, for example, if this is an accessor method, you get

	Click ON              Popup 
        "comment"       Text box editor with body of comment -OR- simply
                                    reuse the Attributes "documentation" editing box within
                                    the class attributes edit dialog.
   	"public"		     UMLAttribute properties dialog for "MyAttribute"
	"Object" 	     UMLAttribute properties dialog for "MyAttribute"
	"<void>"	     UMLAttribute properties dialog for "MyAttribute" (or, perhaps, its NOT clickable)
	"<body>"		Text box editor with just the body of the code.

	If this is an operation, then its the same thing, but substitute 
	"UMLAttribute properties dialog" with "UMLOperation properties dialog"
	AND the <void> part of the code is definitely clickable and pulls up the 
	Operation properties dialog with the list of current parameters.

	I guess these examples are overkill because basically only 2 popup dialogs
	are used in the Java case. But some languages (like XMLSchema) may require
	more sophisticated linkages between previewed code and  the appropriate
	UMLObject popup dialog. 

	Its all pretty strait-forward (I think) with no place where duplicate information is
	being entered by the user and having to be monitored by Umbrello so its
	not in conflict.

	So to summarize all of the above..

	What the user MAY NOT edit is the actual preview of the code itself where all 
	of this information is assembled. They must use the largely preexisting edit 
	dialogs to change  the appropriate UMLObject in  order to affect a change 
	in the (generated) code. The only addition to current functionality in Umbrello 
	is a text box editor for the body of the code, ideally made part of the 
	current UMLObject popup dialogs as appropriate. Otherwise, we provide a 
	clickable preview of the code as an aid to user navigation to the appropriate 
	popup dialog editor in Umbrello, should they wish to make a change.

						=b.t.
 

-- 

If you _really_ feel this strongly about the bug, you could
either try to increase the number of hours a day for all of
us or you could talk to my boss about hiring me as a consultant
to fix the problem for you on an emergency basis :)

	- Rik van Riel explaining what to do against kernel bugs