node.parent null for non-root nodes

Attribute is a child of the attributed node (in the smodelAttribute role). Does this explain your question?

Unfortunately not.
And I think you misunderstood which Attribute concept I'm speaking about, it's not related with smodel.

I'm referring to a simple Entity/Attribute language which instances could be Person and Department.
You define a type EntityType to be able to have for example Person.dept of type Department, a pattern that you probably know very well.

I the instance of EntityType that define the type of the instance Attribute "dept" to be Department, it has parent = null whereas I thought it should point to the "dept" instance.

I see. I suspect you are testing a parent on a calculated type, not a "type" child of an Attribute.
Could it be that you are returning a calculated type in the "$COPY_SRC$[string] someMember" macro when LOOPing over attributes of an entity? This would then result in an orphaned EntityType instance being reduced and thus passed into the reference macro, I think.

I wonder if the completion dialog in the inspector for the $COPY_SRC$ macro gives you two options for "type", one being the calculate type and the other being the type child of Attribute.

Vaclav

You are right: inside my COPY_SRC macros copied nodes are orphaned, not matter if they are of type EntityType or other types (I made some tests).
Even if I don't understand why, thanks for your explanation now I know I should not rely on parent in these contexts.

I'd be curious to see what code you have in the $COPY_SRC$ macro that it makes the node detached from its parent. Normally you can rely on the parent to be present on the nodes passed into macros.

Mine code, which follows the tutorial, behaves as you'd expect:

$MAP_SRC$entity2class 
public class $map_Entity { 
  $LOOP$private $COPY_SRC$Object $field = null; 
}

Inspector for the $COPY_SRC$ macro:

(genContext, node, operationContext)->node<> { 
  node.myType; 
}

Vaclav

From your previous message I understood to be normal that copied node is orphaned in COPY_SRC macro.
Probably I misunderstood it, see my code below for your curiosity.
I put an extra System.out.println() into the code for clarity.

Into my language I can define an Attribute of type List, in this case I can specify the type of its elements:

list<ReceiptLine> lines

The reduction rule for ListType is:

concept ListType   --> <T  ArrayList<$COPY_SRC$string>  T> 

inheritors false              
condition <always>            

Inside the COPY_SRC macro I have:

(genContext, node, operationContext)->node<> { 
  System.out.println("Here node.parent is null: " + node.parent); 
  node.elementType; 
}

During generation I get this on standard ouput:

Here node.parent is null: null

It seems you have progressed beyond the original tutorial quite a bit.
I'd still be curious to see the details of the $COPY_SRC$ macro that is used to specify the type of the generated Java fields - the one wrapped in a $LOOP$ over entity's attribute, defined inside the root template for Entity. I suspect this might be the place that needs tweaking.

In fact my template is not for Entity but for EntityReference because I have a sort of container (actually indicated into the Abandon roots) where I list for which Entity I want to generate java class.

Below the piece of the EntityReference template that generate the Java field:

$LOOP$entityField[private $COPY_SRC$[String] $[myField];]

Inside LOOP node is EntityReference so the LOOP macro is as follow:

(genContext, node, operationContext)->sequence<node<>> { 
  node.entity.attributes; 
}

The COPY_SRC macro you requested is:

(genContext, node, operationContext)->node<> { 
  node.type; 
}

Finally the property macro for myField is:

(templateValue, genContext, node, operationContext)->string { 
  node.name; 
}

Let me know if you are interested in further details.

I see. I wonder what the "node.type" in the $COPY_SRC$ macro refers to. If you attempt to code-complete it, you need to choose the "type" link, not the "type" (aka calculated type or get type). See the screen-shot.

I think this is ok, I have just one option for "type" see the attached image.
In case I can zip and post here the whole project.

In that case, I'd be really interested in seeing the project, because I struggle to understand what could be wrong here.

Here the tgz file, generate the supermarket.java java solution and look at the Messages window.
The show warning message you are interested in is inside the reduction rule for ListType.
hearepy.tgz (174KB)

Hello Marco,

sorry for the delay - we needed to do some investigation on this one, because normally the nodes passed into macros are contained in the AST and thus have their parents properly set.

In your project, however, the model containing the ListType is a different model from the model being generated (containing the EntityContainer), which is not a typical scenario.
Since it causes these troubles, we will revisit the mechanism of generating nodes from the other models in one of the next releases.

Vaclav