Well...although my time to work on this got severely cut today, I did get enough of an opportunity to confirm that this is going to work - quite nicely! I do have some details left to work out, and a sizable amount of code to write, but the most important tests were successful.
I'm going to continue on here, adding on to my original concept - with more details about how this is going to work. Of course, everything is subject to change if it's required, as I go along - but a much clearer picture is starting to emerge.
First off, a copy of the test markup I'm using for testing things out
Code:
xmltest=[[
<Element ID="mainSquare" type="Window" x="200" y="200" width="400" height="400" bgcolor="#ff0000">
<Element ID="smallSquare" type="Window" x="220" y="220" width="100" height="100" bgcolor="#00ff00"/>
</Element>
]]
Very similar to the example I posted above - this time taking advantage of the third Lua option (other than single/double quotes) for doing strings. Also changed, is trimming down the class types to a more simplified name (The UI.LotRO version of the window class would be something more along the lines of "LotroWindow" or something similar. Since there's no way to really convert a string to a class directly, I don't have to go with something ridiculous like the full class path.
At this point, the process is going to go something like this:
1) import the UI.lua script
2) parse the document(s) building a "NodeTree", consisting of "Node"s, that will contain a table of parameters, a table of childNodes, the ID, and the type of node
3) Once the markup language is in a far more development/lua friendly format, the NodeTree will be traversed and the elements will be generated. I still have to decide on exactly how final interaction is going to take place, but for now, I think I'm going to go with storing the generated element in its node, and then "dumping" the elements to the screen - to give the developer control over the visibility of the generated UI, as well as allow for easier access to the individual elements.
Some details about the structure of the project:
Although the complete package is a means to an easier way of designing a UI with plugins, I see the opportunity for at least part of it to serve other needs. For that reason, this project will actually consist of two separate libraries, keeping all the XML parsing/navigation/management separate from the UI generation. This way, as the plugin system moves forward, and more data hungry plugins are created - authors will be able to easily provide updates and changes to their plugins, by using a common data structure, without having to generate (significant) Lua code in order to do so.
That's the extent of what I have for today - another update will come Sunday - with hopefully more than just plans to show for it
