Transformation alternative

[thomaskilian]

To whom it may concern.

I just had the idea to not using this (limited) transformation tool. Instead I use the EXEC_ADD_IN to create the intermediate file completely out of my add-in environment. I just have the file wrapper which calls the class macro where the EXEC_ADD_IN is located. This way I have much more possibilities to create the intermediate file than using the provided substitution macros.

[«Midnight»]

If I understand you, in essence you are somehow 'hooking' EXEC_ADD_IN when it would normally be time to do a transformation. The add-in then takes over and does whatever it is you want - which may be quite a bit more detailed than an EA transformation script. Finally, you and control back and things continue from the point where your 'transformation' was invoked.

Am I reading you correctly Thomas?

[thomaskilian]

Exactly, David! Here's the File macro

Code: [Select]

Package {
 name="CONTROL"
 Package {
   name="DataAccess"
   namespaceroot="true"

%list="Class" @separator="\n\n" @indent="    "%
 }
}
And here my Class macro

Code: [Select]

%EXEC_ADD_IN ("SimpleEA", "EA_exec_add_in", "Automation/test", classGUID)%

I use Perl for coding, so my add-in is fixed and the script name (Automation/test.pl) is passed for dynamic substitution. The only parameter of worth is the classGUID. Inside my script I evaluate this GUID and spit out the complete intermediate data (Class {...}, etc.) I really would like to see the intermediate file's syntax, as I guessed it only from other transformations.

[Eve]

Thomas,

What you're doing isn't exactly a new idea to us here.  It was one of the possibilities that doing transformations in this way allowed.

I'd still recommend making smaller calls to do this things that you can't do, or are difficult to do in the templates.  There are some things that the templates do make very easy.

By all means, though.  Do this and I hope it goes really well for you.

PS. We have heard the calls for a more defined syntax for the intermediary file.  Part of the difficulty is that the grammar actually obscures the structure instead of making it clearer.

[Paolo F Cantoni]

PS. We have heard the calls for a more defined syntax for the intermediary file.  Part of the difficulty is that the grammar actually obscures the structure instead of making it clearer.

Must be some food for thought there...


Paolo

[Eve]

Must be some food for thought there...

Actually, the format is very simple.  It has already been described in the help.  What is missing is the list of what everything can contain.  A grammar is a bad way of representing that.

[thomaskilian]

Simon,
as you parse the file with an automate, there MUST be a syntax. I guess the problem is the context. Using a context sensitive grammar is always a pain. However, it should be possible to publish the context free grammar with some context information in "human readable" format.