RE: [gmt-dev] The future of Fuut-je

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Hi Ghica

> My points are:
> ·	Ease of use.
> ·	Extensibility of the tool itself by the users
> ·	Use it as a platform meta-level generation tool
> ·	Adaptability of the code generation templates
> ·	Generate applications for any kind of environment

Some of these are highly subjective, so Fuutje must coexist with
tools and representations that suit other prejudices.
 
> Proposal:
> Take the batch facilities of Fuut-je and put this into a 
> separate package,
> together with all modules that could run with it. This is a 
> part of Fuut-je
> that can run independently of Swing, where you are still able 
> to load/save
> models and to generate code. This will result an a headless version of
> Fuut-je. :-( (The head is the most beautiful part of a 
> "fuut", Dutch for
> "great crested grebe").

Excellent. This is exactly what I was trying to persuade you to do
so that the built-in Fuutje transformations can be exploited in conjunction
with other transformations/representations.

Please try to ensure a nice clean simple API so that I can integrate
the headless Fuutje into OMELET - the practical implementation of my
GMT framework proposal. OMELET 0.0.1 is now available, and I am assured
that the official Eclipse project really will be up very soon. In the
meantime the feature can be requested from me by email.

With the basic any transformation/any representation principles in place,
I am just about to start looking at the problem of making many different
schema representations (XSD, MOF, eCore, UMLX, Fuutje, ...) coexist
and inter-transform.

WRT Swing/SWT, I suspect there are two different areas of functionality.

The model editor needs consideration in conjunction with GME, EclipseUML,
EMF, GEF, ... so that Eclipse has one good quality extensible tool for
editing
DSL, UML, MOF models. Please don't produce yet another inadequate editor.

The editor generator needs consideration in conjunction with EMF which has
related functionality. Ideally the generator would support Swing or SWT
or whatever (even MFC!), so perhaps the generator should be layered:
	- establish editing class model (in generic OO concepts)
	- map editing model to target class model (SWT, Swing, ...)
	- map generic OO concepts to language-specific concepts
	- transliterate to textual language form

	Regards
			
		Ed Willink

------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@xxxxxxx
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------