[Uml-devel] kdesdk/umbrello/umbrello/codegenerators

[Brian Thomas]

On Thursday 27 March 2003 04:01 pm, Jonathan wrote:
>
> On Tue, 25 Mar 2003, Brian Thomas wrote:
> > CVS commit by thomas:
> >
> > Added this class to the project as a means for code generators to
> > reuse common code that will summarize important aspects of classifiers,
> > tasks such as finding all the owned classfiers in association with the
> > current classifier, whether or not its an interface or class, and any
> > static attributes, etc are in this class. More methods should be added as
> > utility is recognized. Because this is forseen to only be used by code
> > generators, I have placed it along side of them in the codegenerators
> > sub-directory..appropriate?
>
> All looks good with the new cppwriter stuff Brian.  Well done.

	:)
>
> The Abstract Class header which gets printed out on Interfaces might need
> to be i18n()ed I'm not sure.  Maybe a separate headers/ file could be
> used.

	Hum. Feeling lazy just now.  Im not sure where that change would go, if you 
	see a quick way to punch it into the code, please do so. 

	Overall I had forgot about internationalization of output text (well, you know Im an 
	American, so "unilateralism" is a common philosophy over here). Could there
	be other spots in the various writers that need the i18n() call on them? I also still
	think it a good idea to be more flexible about line ending characters (\n vs \r vs \n\r)
	as code generated might be slated to run on a non-UNIX platform.

	Speaking of code generators, Im in the middle of a re-design of the code generation
	system. I cant figure out if it is better to integrate the ability to specify language specific
	parameters within the class diagram dialogs (e.g if you click on a class attribute, and 
	have code generation set to "CPP" you should have the option of making that attribute
	"virtual") OR to have a completely separate interface where the code is edited on (lightly, I 
	dont want to reinvent kdevelop here!!) and edits saved in a template. The last option what
	the basis of my first code generation redesign proposal. Any thoughts on this? How far
	should one be allowed to specify the code generation? I had thought that at least being able
	to control whether things like auto-generating accessor methods and providing the guts
	of operations as a baseline. Having the code editor synced back to the class diagram itself,
	so that changes to the class code document propagates back to the original class is a bit
	too much to chew at this time. Similarly support for compiling, debuging and fancy editing
	(like being able to find/replace snippets of code thoughout a project) are out.


					-b.t.

>
> Jonathan

-