Trying to read on RSG, i can't help but notice there are so many weird contraptions in Roku's xmlography that remind me the saying:
The difference between a clever man and a wise man is that
- the clever man can extricate himself from difficult and intricate situations that
- the wise man would never have gotten into in the first place
To wit, the just documented
magic XML attribute "role
", described understatedly as:
The Scene Graph node markup elements contained in the <children> element may include a special XML element attribute, role. The role attribute allows a node element to be defined as a child node of a parent node, and the child node to be assigned as the value of the parent node field identified by the role attribute value
Translation: because XML cannot have structured attribute values
(only strings), let's flex shoving head between the legs. I found a good visual for the situation - it's yoga's Karnapid asana
[/spoiler:3pbguhi7] In fact t seems such a good fit, that i propose Karnapidasana for official logo of Roku Scene Graph!
Check out the "interface fingers" - such a nice touch.
You'd think the Maker of RSG would have wisened up the first time they scribbled down something like:
translation = "[130, 160]"
rowItemSize = "[ [536, 308] ]"
Shiver me timbers, structures in strings surely give me
pause. But apparently not to the Maker, who'd rather extricate himself with wickedly clever hacks from a corner where a wise man would have never painted himself in the first place. Roku's "SDK2.0" is full of valiant contortions in attempt to (a)dress the self-inflicted wounds of committing to XML for SG!
What's the alternative, you may ask? Using pure BrightScript for SG instead of XML
comes to mind - B/S nested structures have none of the XML limitations - nor for that matter would you have to write your functions into <![CDATA[ ]]> text blobs nor exile them to different files (cue yoga uri
Couple of months ago I whipped a sample BrightScript syntax
for SG in an afternoon - mind you, not the only approach but a reasonable one - and would have implemented and using it by now if the "BrightScript/XML Markup Equivalence" were complete - which it isn't
. RSG remains belligerently hostile to BrightScript functions
^ - they are not allowed as field types, get stripped on structure copy, can't pass them between threads nor re-assign them to events like init()
(^) even as functions in B/S are literals, completely lacking context/closures - the one true advantage, a blessing-in-disguise that BrightScript has here over all other scripting languages