[Uml-devel] codegenerators

[Jonathan Riddell]

On Fri, 4 Apr 2003, Brian Thomas wrote:

> 	Well, I actually agree with this approach (mostly). I think people
> 	on this list are getting overly ambitious about what can be accomplished
> 	and _should_ be accomplished by Umbrello. Like I have said before,
> 	I dont want to implement an IDE within Umbrello. The requirements for
> 	"code editing and generation" as I see it are the following:
>
> 	1. Be able to control parameters of code generation better. Language
> 	     specific parameters (such as whether or not to allow auto-generation
> 	     of accessor method for a given class, what kind of "list" variable to
> 	     use, etc) are controlable.
>
> 	2. Be able to insert code into operations (including any accessor
> 	methods too).
>
> 	3. Be able to insert arbitrary code/text into almost any point in a file.

I'm not convinced at the need for this /within/ Umbrello.  If the file is
edited outside Umbrello the changes shouldn't be overwritten but I'm not
convinced for a need to start an editor from Umbrello.  Don't know if
that's what you meant or not.

> 	4. Be able to save these changes to code generation to a "template"

Ideally there wouldn't be any template, only the Umbrello file and the
generated code files.

> 	There are other mentioned requirements on this list which I _dont_
> 	want to address and seem to center around the following :
>
> 	- have code editor which is able to do fancy things like code
> 	highlighting, find/replace, auto-indenting, etc. In other words embed a
> 	 "real" editor within Umbrello.
>
> 	- have ablilty to set the type of embedded editor.

Yes

> 	- have changes made in the editor propagate back into UML diagrams.

Yes but there should be a code import function which would preferably be
more advanced and extendable that what we have today.

> 	From my point of view, the code "viewer/editor" is very simple. It allows
> 	you to inspect the type of code that will be created, it allows insertion of
> 	operation/method code and it remembers it. It also controls some code
> 	generation parameters, but changing things which are handled already
> 	by the UML diagrams is NOT allowed (e.g. renaming a class or
> 	attribute). Having this kind of control will help solve the issue of syncing
> 	up the UML diagrams with generated code...

I'm not even sure that you want to go that far. If you start having any
sort of editor people will expect full editor functions else they may as
well use their normal editor.  I'd say just let them set the
configurations and let them add code however they normally would.


Jonathan Riddell