Support explicit DataTypeRegister setup for DataModel.

[eugeneko]

Per my comments in Gitter.
This ability to manage lifetime of the registry solves the crash that happens on DLL unload when this DLL creates RmlUI models.

[mikke89]

First I want to say, in general I'd be worried about using the data model functionality across DLL boundaries. It depends on uniquely generated type ids, which might conflict across boundaries.

Other potential approaches could be:

• Construct separate contexts for each DLL.
• Make a Context::ResetDataModels function (which also clears the type registry).
• With your PR, one can be careful about using one type registry per DLL. I guess perhaps this is your intention? If so, should probably document this somewhere. I guess this would also take care of my initial worry above, although at the expense of needing to be careful when constructing new data models.

With that said, this proposal is not very invasive, so I would be okay with adding it - please see the suggested changes.

[eugeneko]

First I want to say, in general I'd be worried about using the data model functionality across DLL boundaries. It depends on uniquely generated type ids, which might conflict across boundaries.

With your PR, one can be careful about using one type registry per DLL. I guess perhaps this is your intention? If so, should probably document this somewhere. I guess this would also take care of my initial worry above, although at the expense of needing to be careful when constructing new data models.

Yep, my intention is to allow users to work within DLL boundaries instead of automatic and invasive magic in the Context.

I am not sure about having multiple contexts, because we may have multiple DLLs with multiple isolated data models, that all render to the same window as independent documents. Multiple contexts will probably cause more separation than I want. If documents live in separate contexts, I cannot really have them working together with correct focus transitions and stuff, right?

About your comments, I will revisit this PR at some point.

[eugeneko]

About your concerns regarding DLL boundaries, I like the approach of EnTT.
They have their fair share of template IDs, but they provided alternative API that is module-agnostic and therefore it works reliably regardless of the boundaries. EnTT allowed users to provide type IDs manually by tagging the types somehow.
They may have changed something since I last used it across the boundaries.

It's not crucial for me to have now, but it is a nice thing to have boundary-agnostic API.

[mikke89]

Yeah, multiple contexts might be complicated if you need things to interact, or documents to overlap in arbitrary order. I think your approach makes sense so I'm fine with this direction. As for boundary-agnostic API, that sounds good too, although it's not a priority for me personally.

I fixed some build warnings in the master branch, so you might want to rebase this when you make your changes.

[eugeneko]

@mikke89 Should be good to go now

[mikke89]

Looks good, thanks for finishing up this one.