-
Notifications
You must be signed in to change notification settings - Fork 0
"$: Shape" vs "Shape: [" #1
Comments
"Shape": [Let's say we use the second syntax: it's great when there is only one node of each type, that the container property is obvious and if you don't mind losing the order of the nodes (given the parser might re-order properties alphabetically): {
"Group": {
...
"Transform": {
...
},
"Shape": {
...
}
}
} How would you make a Group that contains a Shape, a Transform and another Shape ? {
"Group": {
...
"Shape": {
...
},
"Transform": {
...
},
"Shape": {
...
}
}
} So it would probably end up like this, which is already 5 levels of nesting: {
"Group": {
...
"@children": [
{
"Shape": {
...
}
},
{
"Transform": {
...
}
},
{
"Shape": {
...
}
}
]
}
} If you don't mind losing the order of nodes and if there is only one possibly property where children nodes are meant to be stored, you could group nodes by type: {
"Group": {
...
"Shape": [
{
...
},
{
...
}
],
"Transform": [
{
...
}
]
}
} But if you have a special node with two MFNode properties that both expect Shape/Transform nodes, it would have to specify the container property and you're back to 5 levels of nesting: {
"SpecialGroup": {
...
{
"@someChildren": {
"Shape": [
{
...
},
{
...
}
],
"Transform": [
{
...
}
]
},
"@otherChildren": {
"Shape": [
{
...
},
{
...
}
],
"Transform": [
{
...
}
]
}
}
}
} $Compare to this structure: {
"$": "Group",
...
"children": [
{
"$": "Shape"
...
},
{
"$": "Transform"
...
},
{
"$": "Shape"
...
}
]
} Its advantages:
|
This was a question from the X3D mailing-list:
(Edit:
$
used to be named_type
at the time)The text was updated successfully, but these errors were encountered: