[great-users] Suggestions for new GReAT features

[Gabriele Trombetti]

First of all I have to say that this GReAT is REALLY EXCELLENT!! An 
incredible time saver.

Here is what I would suggest as new features, after some use of GReAT:


---- Feature to let the user enter additional include files for a GReAT 
project, and additional .cpp files to be compiled and linked to the dll 
or exe (the user would write those .h and .cpp files somewhere, for 
example in the MetaInformation of the Configuration)

This is because doing something slightly different than what GReAT was 
first thought to do, is terribly complicated. Of the generic libraries 
we only have some STL and the <stdio.h> which was just barely enough to 
do what I wanted, in a very contorted manner (the api for filesystem 
access are very very very minimal!!).

Allowing a separate .cpp file to be linked into the project (and its 
correspondent .h file) would also allow us to call complicated custom 
functions inside the aspect mappings, which could be reused in OTHER 
aspect mappings of the same project without needing to copy and paste 
them into different places. And also consider that nested functions are 
illegal in C++ so currently we cannot really create a "function" inside 
an aspect mapping (that is something that can be called multiple times 
with different parameters), so we have to emulate it with for and while 
loops.

A third reason is to allow us to fix a few inconsistencies of GReAT 
e.g.: in my project I used a UdmDataNetwork, which worked into the 
interpretative transformation (Aspect Mapping), but when I generated the 
.cpp/.h code the UdmDom.h was not #included so it would not compile and 
I had to modify the .cpp file by hand (and I will need to modify it 
again every time I change the transformation and I regenerate the code). 
If I had the custom #include support in GReAT, I would simply add the 
UdmDom.h there once for all.

Note that for a first cut of this feature, the user #include support 
could even be enough by itself (that is, without the additional cpp 
files linking) because in theory one can put all the functions, 
including implementations, into an .h file, and he could do custom 
linking to additional C runtime libraries with #pragma comment(linker, 
......) from there.


---- Use and *preserve* relative paths for the .xsd and .dtd files!!
Contrary to the manual, it seems that GReAT accepts relative paths for 
the .xsd and .dtd file in the configuration, but when the xml file are 
written, the xsi:noNamespaceSchemaLocation which is written into them 
will point to the schema with the *full path* which means that if you 
move THAT xml file to another computer, it will not be possible to open 
it with xerces, GReAT or anything else ("Unknown element MyRootElem") 
without first editing it by hand.

Luckily, the exe which gets out of the GenerateCode seems to preserve 
the relative path of the xsd (that is, the xml files written by the 
standalone .exe have a xsi:noNamespaceSchemaLocation with the relative 
path).



---- Dump the Aspect Mapping to c++ without removing the linebreaks
So that we can use the // comments, and more importantly, if there is a 
compile error in a complicated aspect mapping, we can see *which* line 
caused the error!



Thanks
Gabriele Trombetti