Feature request: field iteration

[John Hahn]

Let's say I have a game level editor, and I want to display a property grid in this editor that shows all the fields in a given struct or table.

Is such a thing possible currently?   It would be cool to have an interface along these lines:

schemaObject.getFieldNames(std::vector<std::string>& fieldNames);
for (i = 0; i < fieldNames.size(); ++i)
{
    FieldType fieldType = schemaObject.getFieldType(fieldNames[i]);
    switch(fieldType)
    {
    case FieldType_INT:
        {
            int fieldValue = schemaObject.getFieldValue<int>(fieldNames[i]));
            addIntToPropertyGrid(fieldNames[i], fieldValue));
        }
        break;

    case FieldType_FLOAT:
        {
            float fieldValue = schemaObject.getFieldValue<float>(fieldNames[i]));
            addFloatToPropertyGrid(fieldNames[i], fieldValue));
        }
        break;
    }
}

[Wouter van Oortmerssen]

Hi John! Nice to hear from you :)

This information sorta-kinda exist, if you parse a schema with the Parser class, it will get populated with a list of StructDefs and such that give you access to field information. At the moment though, this is private, and doesn't come with handy functions to actually read the data from a FlatBuffer. I should add that.

The bigger issue is that if you had this, it still wouldn't help you much in creating an editor for this data, since FlatBuffers are currently read-only, so you'd still need to store modified values elsewhere. Mutable data is a use case we may want to support out of the box at some point, but I am still not convinced what is the best solution there (directly modifying the FlatBuffer, which is limited, vs a set of shadow objects, which would need memory allocation).

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Hahn]

Hey Wouter!  I knew you were at Google, but I didn't know what you were working on.  This is a cool project.

It seems like this might be the right way to go then:

• Editor reads/writes JSON (just for convenience of version controlling)
• Cook/build tool scans the project data directories for JSON files and generate flatbuffers from them
  
• Runtime loads the flatbuffers

The problem with this approach is that it means we essentially have 2 keep track of 2 schemas and make sure they maintain parity.    Anytime I modify a flatbuffer schema, I have to modify the corresponding shadow object that the editor uses.  Perhaps a new flag could be added to flatc so that you could do something like this:

flatc -c Monster.fbs --edit-mode

And with this flag it would generate 2 headers:

• Monster_generated.h
• The regular flatbuffer header, and it would be included in the runtime.
  
• Monster_edit_generated.h
• Used by the editor to read/write JSON files

This way we have 1 schema file that generates both the regular flatbuffer header and the shadow object header for the editor.

[Wouter van Oortmerssen]

The current implementation already supports reading from / writing to JSON. But it converts it to a FlatBuffer during parsing, so it has the same lack of introspection.

--