Naming problem when using transfomation to C#

[Ophir Yoktan]

Hi,

I'm trying to create a transformation between my abstract classes (language = <none>) to C# classes.
public attributes in the classes are converted to private fields, and public c# properties.
The names of the generated fields and properties are identical, and causes collisions.
Is it possible to generate the fields with some kind of prefix to avoid the problem?
(I assume editing the transformation templates might help, but I'm not sure where and how exactly)

[«Midnight»]

Hi Ophir,

Yes you can. Don't tear up the templates just yet, or at least not just for this.

Open the Tools | Options | Source Code Engineering dialog. Near the bottom you'll see a block of settings under the line of text beginning with "Remove prefixes..." Set up your attributes with the prefix and check the Property box. When EA generates code for the properties it will remove the prefix, avoiding the collision.

HTH, David

[Eve]

Of course, if you don't want to include the prefix in your original model, you will need to modify the attribute and connector templates to add a prefix into the name.

You would then need to modify the Attribute__Property and Linked Attribute templates to change the attribute_name tagged value to match up with the correct prefix.

[Ophir Yoktan]

Of course, if you don't want to include the prefix in your original model, you will need to modify the attribute and connector templates to add a prefix into the name.

You would then need to modify the Attribute__Property and Linked Attribute templates to change the attribute_name tagged value to match up with the correct prefix.

This appears to be what I need, however I didn't find out the right syntax to change
%Property(attName,$type)%
to
%Property(prefix + attName,$type)%

Ophir

[Eve]

You'll need to explicitly assign the concatenated string to a variable.

For a literal string as the prefix.
$attName = "m_" + %attName%

For a variable as the prefix.
$attName = $prefix + %attName%

For both.
%Property($attName, $type)%

[Ophir Yoktan]

Thanks,

this adds a prefix to the property name.

What I want is to add a prefix to the member variable, and not the property name.

I tried doing a similar change in the Attribute template.
the names were correct, but the generated property code pointed to the unprefixed member name.

Ophir

[philchudley]

My simple answer would be, if the property code is incorrect, then modify the Property macro to also use your prefix as in the Attribute  macro

Cheers

[frik_stuart]

There is another alternative. EA provides a mechanism for you to associate the property and underlying attribute, and lets you choose a name for the Property.

Do the following:
- Go to the Attributes dialog for you class and select the attribute that you want a property for.
- Check the "Property" checkbox. This will bring up a dialog called "Create Property Implementation"
- You can specify the name of the Property in the "Name" field and also specify whether you want Get and/or Set scope

Although you will have to do this for all your properties, it does provide better control than changing the generation templates which may cause you pain in future when you upgrade your EA version etc.

[hroberts]

You can modify the property stereotype for the operation template and accomplish this.   I did this exact same thing for vb.net generation.

[Matt Edwards]

Hi Ophir,

Yes you can. Don't tear up the templates just yet, or at least not just for this.

Open the Tools | Options | Source Code Engineering dialog. Near the bottom you'll see a block of settings under the line of text beginning with "Remove prefixes..." Set up your attributes with the prefix and check the Property box. When EA generates code for the properties it will remove the prefix, avoiding the collision.

HTH, David

This seems a little backward -- usually you only want to diagram the public interface, with property code being generated as it appears in the model. This setting should allow one to add a prefix to the private implementation field, which noone will ever see or care about.

[«Midnight»]

You could look at it that way. But try a different viewpoint and it might seem more natural...

You might want to ensure different names for the private (internal) variable name and the public property name. Some (many) languages enforce this by disallowing field and variables with the same name.

This way you can decide that the public interface will have 'natural' names - the ones you will show on a structural diagram during design. You can now 'denature' (for lack of a better term) these names for the internal code. The internal names will be private (or protected or whatever) and not (usually) shown on high-level design diagrams. The internal names should follow some kind of simple convention. EA allows you to do this via the settings we've discussed, then generates code in a predictable manner while conforming to the expectations set out above.

I'm neither supporting nor defending the EA implementation, just saying that it works.

One thing that (IMHO) could be improved is to add the ability to override it for each language. The current implementation would remain, becoming the default for cases where no explicit override was specified. [That means that there would have to be some way to explicitly clear the setting for each language.] This seems (again, IMHO) to be something that would fit well withing the paradigm that EA uses for language options.

David