Anonymous/ElementDocument-bound data models

[TheEclectus]

Hello,

I've run into a bit of a wall regarding data models. My intent was to be able to have multiple ElementDocuments utilizing the same .rml source, but be bound to different data models. The goal here is to be able to have, say, multiple inventory screens that a player can transfer items between, or multiple entity viewer windows that show simple stats about each entity.

I'd figured that there were a few possible angles to approach this from:

1. A model could be generated based off of a unique identifier, and the proper data-model attribute overwritten with the model name at runtime. The model would be managed in the background by a helper class to update them appropriately. This seems like the most viable option, even if a bit cumbersome.
2. A single model could be used, and have a piece of userdata (either an attribute, a two-way data view, or a raw pointer attached to the ElementDocument itself) used to modulate the getters/setters set on the model that return the data proper. To my understanding, it would take some source-level modification to make pointer-based userdata possible.
3. The ElementDocument could be programmatically modified at runtime by altering the attributes/text of certain nodes in the DOM, either by id or class. This seems like it would be the most-cumbersome solution.

Is there perhaps a more elegant way to accomplish this that I'm overlooking? Thank you.

[mikke89]

Hi.

Thanks for the suggestion, this is indeed a use case I would like to support better. Here comes my thoughts and suggestions.

I believe a solution along your first one should indeed be quite simple to implement. I'd suggest something akin to Context::SetDataModelAlias which would just map a model name for a new one in the context. This alias would be overwritable so that the client can set it before the document is loaded, or we could make it a callback function.

As you say, this approach would be a bit cumbersome to use since we have to make a new data-model for every open window. And all of these data-models would be structured the same, so we would be repeating ourselves a bit. We might also need to close the window and reopen it to point it to another entity.

On first glance, I don't see how solutions 2 and 3 would be implemented, so I'm a bit worried they could easily become complicated. My immediate reaction is solution 2 could be worth looking into, but probably not solution 3.

I have one other suggestion. This would be based on top of another feature request someone has asked about previously, namely allowing indexing into an Array using an arbitrary data address instead of just a number. The other component we would need is to somehow fetch a unique ID for the current document. Somehow we need to let the client bind a callback function which should take the current document (or even the current element) and return an integer ID. It would be similar to the current BindFunc callbacks, we just need to feed the document/element pointer down there somehow.

With these two components we could simply index into an array of structs with the current ID based on the current document. If we want to change the entity, we update the ID (and dirty the corresponding data variable) and it all just works out. No need to create a new data model or re-open the window. These two features could probably be useful in other cases as well which is why I kind of like it.

[TheEclectus]

I quite like the idea of documents having a unique ID and accessing an array in an existing data model that way! It feels very robust by comparison to the other ideas and could have a number of applications. An emulation of an inexpensive per-document data model could be emulated by using BindFunc to pass getters and setters that use the document ID to access, say, variables from a Lua state, for instance.

How do you think accessing the variable through a document's Rml? I'd propose a reserved variable name in the style of Lua (e.g. '__docID'), or perhaps a symbol accessed in the same way any other model scalar would ({{ # }}, {{ documentData[#].text }}, etc.).

[mikke89]

Nice to hear you like the idea.

I was thinking, instead of a dedicated variable name, the user could bind them through the model constructor and return an ID however they like.

constructor.BindFuncPlusPlus("id", [](Element* element, Variant& variant) {
    // given a mapping, eg: std::map<Rml::ElementDocument* key, int entity_id> entity_map
    variant = entity_map[ element->GetOwnerDocument() ];
    // or, we could use attributes
    variant = element->GetOwnerDocument()->GetAttribute("id", 0);
});

To access it in RML we write eg. {{ entities[id].text }}. Whenever the entity map changes, the user can simply do model_handle->DirtyVariable("id") to update all the ids.

One advantage with a callback is that the ID can be retrieved immediately straight after loading, instead of waiting for the user to set some value manually on the document after it has loaded. The latter I can see leading to warnings if the initial ID is invalid. There is also no limit to the number of ID-like variables you can have, possibly with different values for different types.

Implementation- and performance-wise it may be simpler and faster to only provide ElementDocument* instead of Element*. Then we could cache all usage of id in the same document instead of having to retrieve it for every element when it is dirtied.