Preserve manual code on codegen

[RIL]

Hi,

I made my own code gen templates (= has no reverse enginering of code), and now I wonder:

Q: Is it possible to store the manual code (method bodies) in the model (when tested and fine) as to preserve the manually written code if need be to regenerate the class structure?

[qwerty]

AFAIK the method body is stored in Behavior/Initial Code of methods.

q.

[RIL]

OK, I'll try using that.

Thx.

[edit]Yes, works fine.[/edit]

[Eve]

I made my own code gen templates (= has no reverse enginering of code)

Unless you're really keen. (http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/grammar_editor_for_imported_co.html)

[RIL]

I made my own code gen templates (= has no reverse enginering of code)

Unless you're really keen. (http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/grammar_editor_for_imported_co.html)

Thank you very much for this hint!
I managed to parse most of the file level structures for Go, but code body seems to be a little trickier. However, I noticed something that looks like a function call to retrieve a list of keywords in the SSL.nbnf:

// Lexer rules
<TOKENS>    ::= <WHITESPACE> |
                          <COMMENT> |
                          token(<NUMBER>) |
                          token( keywords() ) |
                          ...

Q1: Where can I define such a list of keywords?  Or, perhaps I have missed a basic point sand should instead just go on extending the above list with keywords?

Q2: Is there any .nbnf file for the existing languages available? The language I'm most familiar with is Delphi, so a delphi.nbnf file would quickly get me going with this.

[Eve]

1. The list of keywords is automatically generated based on the string literals in your grammar.
2. No, but there is a sample grammar at EA\Code Samples\Grammar_Samples\SSL.nbnf with a sample file to be parsed by that grammar.

Also, the easiest way to deal with the code body would be using a skip rule.

Code: [Select]

<functionBody> ::= "{" [attribute("CODE", skipBalanced("{", "}", <codeEscape>))] "}";
<codeEscape> ::= <COMMENT> |
                                <stringLiteral> |
                                <characterLiteral>;


[RIL]

...
Also, the easiest way to deal with the code body would be using a skip rule.[/code]

Yes, thank you for that hint, it will become very useful.

// Rolf Lampa

[RIL]

I'm improving. My nBNF/AST parses entire Go packages with all occuring "main" syntax (although skipping the details of function body content as suggested).  I achieve more and more details out of the sources as I learn how to define terms and rules.  But, how do I know...

Q1: ... which exact node/attribute names to give the terms as to enable EA to pick them up?

On the following page(s) on AST nodes I get the following hints about recognizable terms. Does that mean that these names are the exact names by which CodeGen templates uses later when it reads info from the model?

http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/context_labels.html (example node names below)

Q2: If these identifiers are not the exact ones used by EA internally, is there any mapping table resolving the names used in CodeGen templates or via script access?

Q3: In conclusion: Can I access these AST nodes - by these exact names - by codegen or scripts once they are picked up by EA import?

// Rolf

This perhaps should be obvious, but...
(Q4: Does "CLASS/INTERFACE" below mean "in CLASS and/or INTERFACE" or is "CLASS/INTERFACE" an identifier in its own right?)

Code: [Select]

"Class BODY" Node
Contained in Nodes:     CLASS/INTERFACE
------------------------------------
METHOD
ATTRIBUTE
FIELD
CLASS
SCOPE
PROPERTY
TAG
PARENT
OPEN_POSITION
INSERT_POSITION

[Eve]

1. That's the complete list of names EA is looking for when parsing using your grammar. The code templates don't really use them, the code template are generating from your model, not the AST. The AST is only used during generation to synchronize. (eg. Generate new members into a class etc.)
2. In most circumstances it should be self-explanatory what each item on that page corresponds to in the model. If it's not then I'd have deal with those individually.
3. As I said for 1. No, these are used for import into the model. Codegen and scripts will then work on the normal model elements.
4. This allows for nested classes/interfaces.

[RIL]

Ok, clear enough.

Q: Is it possible to somehow print out the resulting AST for a sourcefile?

[highlight][edit]: Ah, saw that you had answered "no" on this last followup question in the other thread.[/highlight]