Blocked: Issue with adding remote attributes to notion

[eric-schleicher]

This is a blocking issue for me.

I'm trying to incorporate data from my ImageBasedVisualization Node Type into the Variable Entity as a notion attribute. I've done this successfully in a number of other scenarios and i'm confused as to why this is a problem.

for context, here are some pictures & descriptions

ImageBasedVisualization

Variable

In Variable I cannot successfully enter the names of the attributes from the remote entity and get the dialog to accept it.

When i use attribute names from abstract node (name, id, type) these columns work, and i get a green flash, but any of the attributes that are actually attributes of the ImageBasedVisualization fail when entering them into the 'Format' box of the related entity.

this is an exmaple input string for the format box: RemoteAttributeName, attributename, attributename, etc...

The Field names that i'm having difficulty with are: xOrigin, yOrigin, xWidth, yWidth, calcXEnd, calcYEnd, projectsOn

I've tried to enter each individually in addition to pasting them as a group, and I'm not able to get any to stick

The following is a example WARNING from the log when trying to add the remote attribute xOrigin
(the format string: hasImageBasedVisualizations, id, type, xOrigin)

Mar 04, 2015 10:28:14 PM org.structr.schema.compiler.NodeExtender$Listener report
WARNING: Unable to compile dynamic entity Variable: cannot find symbol
  symbol:   variable xOrigin
  location: class org.structr.dynamic.ImageBasedVisualization

Please advise

[vigorouscoding]

Hi Eric,

you stumbled upon a difference in dynamic properties and static properties.
This is due to the fact how the dynamic schema is compiled into Java code.

For dynamic properties you can just append "Property" and it should work.
Just use "xOriginProperty" instead of "xOrigin".

Hope that helps!

[eric-schleicher]

Ok I see this works, which is great... a few questions.

Has it always been this way? I've added properties from other entities before and haven't had to do it this way before. was this a recent thing?

Now that i know it's seems ok, but i'll position that this would by highly confusing to anyone who might not be a super aware of how this works under the covers (myself included)

I would propose that an end user should not have to understand this type of subtle detail. Should we make that a feature request?

[amorgner]

Yes, this is confusing and should go into a feature request. Thanks for describing it thoroughly!

[eric-schleicher]

@amorgner ... do we close this or you reclassify?

[amorgner]

I think this even qualifies as bug, so I added the labels accordingly.

[eric-schleicher]

Just checking if i should check current build for this.

if i recall correctly, a fix for this would mean that i no longer need to enter 'Property' after the name of a attribute in the format box

[eric-schleicher]

I've grown accustomed to entering the Property after the attribute names in the notions... the commentary here was that this might be a feature UI? In working towards 2.0 this would seems like the kind of thing that new users shouldn't be presented with ( confusing data entry convention(s) like in this example)

[cmorgner]

What's the status of this issue? Please review and comment or close, thank you!

[eric-schleicher]

I still just enter in 'Property' as a suffix. work for me, but just leaves this as a poweruser have to know feature. if there was UI to pick elements from the existing attributes, then then could be managed under the covers and out of view of the end user.

I would contribute to the KG to document these types of nuances... but haven't gotten any responses on requests to do so.