How define non-Eco attribute?

Question

I need to define som (transient) fields & properties in Eco classes that aren't supported by the Eco framework.

Q: How do I define a field/attribute as "non-Eco" in an Eco class?

Example:

Brep[] SolidHousing; // An array of CAD faces & boxes

//Rolf

Answer 1

You can add transient attributs in dem Modlr but they are also treated by MDriven as attributes and MDriven does not allow arrays, dictionaries or lists in the Modlr.

What you can do is: Simply add them in the .cs file of your class. Don't touch the .eco.cs class but you can do anything you want in the .cs file. Please keep in mind that the class has a generated constructor and that you can add logic in the constructor by implementing the ObjectCreated() partial method. When you take a look into the code in the .eco.cs file, you will understand.

Hint: Normally it's no good idea to add an own constructor without using the Modlr for it.

Already generated constructor:

[GeneratedCodeAttribute("ECO", "7.1.0.0")]
public YourClass(Eco.ObjectRepresentation.IEcoServiceProvider serviceProvider) : 
    base(serviceProvider) {
  try {
    this.ObjectCreated();
  }
  catch (System.Exception ) {
    this.Deinitialize(serviceProvider);
    throw;
  }
}

Answer 2

There are some possibilities you could try. Do you want your Brep data to be persisted? If so, you could write a custom persistence mapper so that this type could get generated and persisted. You cannot model a property of type Brep[] but if you model a transient class Brep, you could add a transient 0..* association to this class which would get a IEcoList which is similar. But the easiest way would be to forget about the model and manually add the Brep[] field or property by hand in the .cs file.

Answer 3

Peter Buchman's answers are good suggestions.

One of the reasons the MDriven framework don't support non-eco style types is that it usually leads down the rabbit hole to non-modelled storage patterns. An array is better served with an association as Peter writes. Of course one can argue that adding support for it wouldn't hurt, but then that also need support, taking time away from more pressing things.

That said, I would suggest the following ways to solve your issues.

1. Add simple attributes in the .cs class as Peter suggests.
2. Maybe make the array into an List<> if that would work for your other code to work with.
3. Implement list manipulation code for your specific needs supporting the Brep[] usage, by having code that acts on the modelled multi-association when accessing the Brep[].