Elements to attributes

[dr_venture]

A big 'for what it's worth here' - expressing a little frustration as I slog through the first stages of learning the FG file structures.

I'm guessing that the XML architecture was inherited by Smiteworks and is 'set in stone' in support of existing rulesets, correct? One thing that makes learning the FG structures a bit painful is their wordy, cluttered depictions by favoring the use of hierarchical elements as opposed to Attributes. This is probably a matter of personal preference, but I've found that in creating large and varied XML documents, it's much easier to read and saves space to use a lot more Attributes , as opposed to mostly Elements. Case in point:

Here's a panel description in the existing structure:



<windowclass name="optionalstats">
<sheetdata>
<genericcontrol name="optionalframe">
<bounds>0,0,100,190</bounds>
</genericcontrol>

<numberfield name="fate" source="abilities.optional.fate">
<anchored>
<to>optionalframe</to>
<position>insidetop</position>
<offset>-20,32</offset>
<size>
<height>30</height>
</size>
</anchored>
<frame>
<name>bonus</name>
<offset>5,5,5,5</offset>
</frame>
<font>sheetnumber</font>
</numberfield>
<sheetlabelsmall>
<anchored>
<to>fate</to>
<position>above</position>
<offset>-20,3</offset>
</anchored>
<static>Fate</static>
</sheetlabelsmall>
</sheetdata>
</windowclass>



... and here's the same code with a preference of using Attributes where possible:



<windowclass name="optionalstats">
<sheetdata>
<genericcontrol name="optionalframe" bounds="0,0,100,190" />

<numberfield name="fate" source="abilities.optional.fate">
<anchored to="optionalframe" position="insidetop" offset="-20,32">
<size height="30" />
</anchored>
<frame name="bonus" offset="5,5,5,5" />
<font name="sheetnumber" />
</numberfield>

<sheetlabelsmall type="static">
<anchored to="fate" position="above" offset="-20,3" />
<text>Fate</text>
</sheetlabelsmall>
</sheetdata>
</windowclass>


To me that second sample is much easier to read and is about 30% more compact. If there's any way to move more in this direction in the future, that'd be my vote.

Yeah, I know, there's probably not much to do about it at this point, but I just wanted to get it off my chest. Thanks for listening. :)

[Griogre]

Out of curiosity, did you try using the second one? It might work. It depends on how the XML encoder/decoder works. I've pull attribues out in xml modules and made them elements and I remembering them working.

[dr_venture]

I suppose some of it might, although I took some liberties in my translation. For instance, in the last 'sheetlabelsmall' I stuck the 'static' tag into an attribute called 'type', just on a guess that it was a logical name. Then I stuck the text into an element called "text" as, again, it seems much more logical to me.

That's really the problem in microcosm to me - stripping it down, this:



<sheetlabelsmall>
<static>Fate</static>
</sheetlabelsmall>

...is less clear to the uninitiated than this:



<sheetlabelsmall type="static">
<text>Fate</text>
</sheetlabelsmall>


...although in this example it's a bit longer. Anyway, at some point I'll mess around with it, but for now, I'm too busy trying not to break things. *tiptoes nervously*

[Emrak]

To me that second sample is much easier to read and is about 30% more compact. If there's any way to move more in this direction in the future, that'd be my vote.

Yeah, I know, there's probably not much to do about it at this point, but I just wanted to get it off my chest. Thanks for listening. :)

I agree wholeheartedly. :)

[Moon Wizard]

The challenge is that the original developers were not consistent in their application of whether child tags and attributes were supported in various situations. Also, I would have to review how templates handled attributes, especially given the mergerule attribute.

In developing rulesets, I tend to err on the side of child tags to avoid unexpected behaviors.

I agree that it would be simpler to read, but not sure it's worth the refactoring development time at this point. I'll add a note to see if I can at least figure out which tags are supported as attributes, and potentially add to the documentation.

Regards,
JPG

[dr_venture]

I agree that it would be simpler to read, but not sure it's worth the refactoring development time at this point. I'll add a note to see if I can at least figure out which tags are supported as attributes, and potentially add to the documentation.

I agree... I figured that this was an inherited situation for you guys. If there's anything to do going forward, that's great, but I know you've got bigger fish to fry these days :)