Add support for nested (dictionary-type) properties #489

Open
LearnCocos2D opened this Issue Aug 4, 2013 · 8 comments

Comments

Projects
None yet
6 participants
@LearnCocos2D

Currently it is not possible to create your own nested properties (like Position, Size). If a single property needs to encode multiple parameters, it needs to be done by embedding all parameters in the same string:

FollowPath | path=p1;speed=10;repeat=0

Or alternatively each property needs to have its own name:

FollowPath | p1
FollowPathSpeed | 10
FollowPathRepeat | 0

Both solutions are supoptimal for editing, and terrible for reading properties in a generic way. For example the above would require reading each property individually, while the example below could be mapped to a "createFollowPath" method that simply gets the properties dictionary passed in. With technologies like KVC (Key Value Coding, ie setting properties in the object hierarchy by key path like "FollowPath.speed") this would lend itself towards more automatisms.

So what I'd really like is to be able to add "dictionary" type of objects. Ideally with unlimited nesting, which once the nesting functionality is there should come natural anyway. The above would then look like this:

V FollowPath
path | p1
speed | 10
repeat | 0

To make this possible the user should be able to create a "dictionary" property.

This could be done by offering another [+] icon next to it, perhaps [++] that creates a property of type dictionary. Then with the dictionary property selected, or one of its children, any click on [+] or [++] adds the new property to the selected dictionary property instead of the root properties.

@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Aug 7, 2013

Owner

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.

Owner

bjorn commented Aug 7, 2013

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.

@LearnCocos2D

This comment has been minimized.

Show comment
Hide comment
@LearnCocos2D

LearnCocos2D Aug 7, 2013

Funny, now that you mention it this is what I happen to have here. ;)

On 07.08.2013, at 20:33, Thorbjørn Lindeijer notifications@github.com wrote:

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.


Reply to this email directly or view it on GitHub.

Funny, now that you mention it this is what I happen to have here. ;)

On 07.08.2013, at 20:33, Thorbjørn Lindeijer notifications@github.com wrote:

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.


Reply to this email directly or view it on GitHub.

@fontmas

This comment has been minimized.

Show comment
Hide comment
@fontmas

fontmas Sep 27, 2014

@bjorn a sugestion for curstom property window could be a sub tree view.

Example idea:
image

fontmas commented Sep 27, 2014

@bjorn a sugestion for curstom property window could be a sub tree view.

Example idea:
image

@fontmas

This comment has been minimized.

Show comment
Hide comment
@fontmas

fontmas Sep 27, 2014

Things to think about and ponder...

Is a nested property could be a nest for others nested properties?

How to could be the format in XML files?

fontmas commented Sep 27, 2014

Things to think about and ponder...

Is a nested property could be a nest for others nested properties?

How to could be the format in XML files?

@Chaoseiro

This comment has been minimized.

Show comment
Hide comment
@Chaoseiro

Chaoseiro Oct 3, 2014

I believe that, at least from a XML standpoint, it could be something like this

<properties>
    <property name="a property" value="some value"/>
    <properties name="maybe a name attribute is unnecessary?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </properties>
    <properties name="nested properties 2">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <properties name="we must go deeper">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <properties name="insanity">
                <property name="limbo" value="true"/>
            </properties>
        </properties>
    </properties>
   </properties>

or, to keep only property nodes inside properties nodes:

<properties>
    <property name="a property" value="some value"/>
    <property name="nested properties 1" value="irrelevant?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </property>
    <property name="nested properties 2" value="irrelevant?">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <property name="we must go deeper" value="irrelevant?">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <property name="insanity" value="irrelevant?">
                <property name="limbo" value="true"/>
            </property >
        </property>
    </property>
   </properties>

I believe that, at least from a XML standpoint, it could be something like this

<properties>
    <property name="a property" value="some value"/>
    <properties name="maybe a name attribute is unnecessary?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </properties>
    <properties name="nested properties 2">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <properties name="we must go deeper">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <properties name="insanity">
                <property name="limbo" value="true"/>
            </properties>
        </properties>
    </properties>
   </properties>

or, to keep only property nodes inside properties nodes:

<properties>
    <property name="a property" value="some value"/>
    <property name="nested properties 1" value="irrelevant?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </property>
    <property name="nested properties 2" value="irrelevant?">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <property name="we must go deeper" value="irrelevant?">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <property name="insanity" value="irrelevant?">
                <property name="limbo" value="true"/>
            </property >
        </property>
    </property>
   </properties>
@theHacker

This comment has been minimized.

Show comment
Hide comment
@theHacker

theHacker Jun 18, 2016

Contributor

I am missing such a feature for a long time.

For a first step (may be this could be an independent feature) I would like to see Tiled not removing custom XML data in a file. Currently if I write my custom tags inside a Tiled file and edit the file with Tiled and save it, Tiled would remove all tags it does not know.

If Tiled would preserve these tags it would be possible to easily save nested properties within the files. Tiled doesn't even have to understand these very game specific properties. The only thing Tiled would have to do is providing a possibility to view and edit these XML fragments.

Custom tags could be nested inside a special tag (for example <custom-properties>) to prevent clashes with existing tags.

With this solution the Tiled file would not be as bloated as with @Chaoseiro's XML and offers more flexibility because you can use tags and attributes as you seem fit.

<properties>
   <!-- Tiled's simple properties -->
</properties>
<custom-properies>
  <a-property>some value</a-property>
  <nested-properties-1 foo="some" bar="value" attributes-as-you="wish">
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
  </nested-properties-1>
  <nested-properties-2><!-- here: no "irrelevant?" -->
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
    <we-must-go-deeper><!-- here: no "irrelevant?" -->
        <are-we-there-yet value="false"/>
        <limbo value="false"/>
        <insanity limbo="true" />
    </we-must-go-deeper>
  </nested-properties-2>
</custom-properies>
Contributor

theHacker commented Jun 18, 2016

I am missing such a feature for a long time.

For a first step (may be this could be an independent feature) I would like to see Tiled not removing custom XML data in a file. Currently if I write my custom tags inside a Tiled file and edit the file with Tiled and save it, Tiled would remove all tags it does not know.

If Tiled would preserve these tags it would be possible to easily save nested properties within the files. Tiled doesn't even have to understand these very game specific properties. The only thing Tiled would have to do is providing a possibility to view and edit these XML fragments.

Custom tags could be nested inside a special tag (for example <custom-properties>) to prevent clashes with existing tags.

With this solution the Tiled file would not be as bloated as with @Chaoseiro's XML and offers more flexibility because you can use tags and attributes as you seem fit.

<properties>
   <!-- Tiled's simple properties -->
</properties>
<custom-properies>
  <a-property>some value</a-property>
  <nested-properties-1 foo="some" bar="value" attributes-as-you="wish">
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
  </nested-properties-1>
  <nested-properties-2><!-- here: no "irrelevant?" -->
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
    <we-must-go-deeper><!-- here: no "irrelevant?" -->
        <are-we-there-yet value="false"/>
        <limbo value="false"/>
        <insanity limbo="true" />
    </we-must-go-deeper>
  </nested-properties-2>
</custom-properies>
@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Jun 19, 2016

Owner

@theHacker I don't really like that approach, because there is no place to keep arbitrary XML data around between loading and saving, and it would be non-trivial to add this. Tiled would have to keep around an XML DOM representation of the original file, and update it with changes made in Tiled before saving it back.

It would also be hard for 3rd party libraries to add support for that, as opposed to the slightly more verbose version proposed by @Chaoseiro.

Owner

bjorn commented Jun 19, 2016

@theHacker I don't really like that approach, because there is no place to keep arbitrary XML data around between loading and saving, and it would be non-trivial to add this. Tiled would have to keep around an XML DOM representation of the original file, and update it with changes made in Tiled before saving it back.

It would also be hard for 3rd party libraries to add support for that, as opposed to the slightly more verbose version proposed by @Chaoseiro.

@kheftel

This comment has been minimized.

Show comment
Hide comment
@kheftel

kheftel Jun 19, 2016

With the new multiline properties, you could put arbitrary JSON or xml data in a string property as a workaround.

kheftel commented Jun 19, 2016

With the new multiline properties, you could put arbitrary JSON or xml data in a string property as a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment