Closed manuelma closed 11 months ago
I suppose we need to require different class names even if the dimensions match? And that's not a bad requirement in any case.
Yes, class names are unique.
We discussed this a little and you could possibly depart from the convention we have been using thus far to better capture the meaning of the multi-d entity... e.g. unit_input_flow__unit_output_flow
rather than unit__to_node__unit__from_node
otherwise, you might need a new convention to signal it's a multi-d entity mith multi-d entities as members. E.g. unit__to_node|unit__from_node
Another option is to do unit__input_flow____unit__output_flow
. I think we need to be really careful about this - it will be long lasting and can be a source of confusion.
Can you use the entities of these multi-D entity classes as dimensions in even higher-D classes?
Can you use the entities of these multi-D entity classes as dimensions in even higher-D classes?
Yes, it never stops. So the dimensions could be themselves entity classes where the dimensions are entity classes where the dimensions are themselves entity classes, and so on
Yes, it never stops.
Should we take it into account with the naming convention? I know underscores are everybody's favorite, but how about some brackets? [[unit__input_flow][unit__output_flow]]
?
Brackets are problematic for SpineInterface, unfortunately. The only thing that works is underscores.
Edit: exclamation points work also. And this: ¤
Sounds like we are on the fast track to underscore heaven, then :P
And this: ¤
I can't even find that one on my keyboard!
This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there
This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there
I'm curious why people need to use that character?
I'm curious why people need to use that character?
You can paste a table directly to the Relationship parameter value table, if you get your vertical bars |
right.
Edit: I think SpineOpt tutorial does this and it fails because the tutorial uses commas.
This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there
I'm curious why people need to use that character?
If I want to paste parameter values into the parameter value pane - I need to recreate the entity list. This is key functionality we should preserve when thinking about how it will work in the future
Edit: Ah @soininen was in first :-)
Ah, thanks
So my initial idea was to use that bar only for displaying data, but whenever the user would copy the data, it would be separated by comma. I guess that changed at some point without me noticing it and now the user needs to deal with that bar.
In my keyboard I can type that bar, must be a windows vs linux thing.
So I guess we need another issue for the bar problem?
Are you sure it's the same bar? I can type a bar |||||| but they're not the right bars
Are you sure it's the same bar? I can type a bar |||||| but they're not the right bars
No, they are different. My key maps to another character than yours.
I think this works now.
This is coming almost for free with the new DB schema since we relaxed the constraint that relationships needed to be composed of objects. Now entity elements can be any entities.
But we probably need to extend
import_entities
so it works with multi-D entities where the elements are also multi-D entities.