I'd recommend dropping the "fields" attribute of your data tag... use
a "name", "varname" or "variable" attribute in the child tag
instead... i.e. this packet:
<data type="struct" fields="my,struct,keys">
<data type="string">blah</data>
<data type="string">blah</data>
<data type="string">blah</data>
</data>
should be this:
<data type="struct">
<data type="string" name="my">blah</data>
<data type="string" name="struct">blah</data>
<data type="string" name="keys">blah</data>
</data>
I say this because I don't like the idea of the contents of the packet
depending on an arbitrary list order in a separate element... the
individual child-elements should be encapsulated so that their order
is irrelevant.
I would probably also drop the type attribute in favor of using
different element names... so instead of having one <data> tag used
everywhere, I'd use several other tag names... In the case of an array
I would of course omit the name attribute and just use the order of
the tags, since the natural semantic of an array is to store things by
position rather than by name:
<struct>
<string name="my">blah</string>
<date name="mydate" value="1/1/1970" />
<number name="mynumber" value="3" />
<array name="myarray">
<string>blah</string>
<number value="3" />
<date value="1/1/1970" />
</array>
<recordset name="myquery">
<record>
<number name="mynumber" value="3" />
<date name="mydate" value="1/1/1970" />
</record>
</recordset>
</struct>
This should be a bit less verbose without losing human legibility. You
could also use a value attribute in the <string> tag since a string is
a simple value and can be represented escaped -- the choice of an end
tag there is mostly stylistic and intended for the sake of potentially
CLOB type data it would (in theory) be clearer to read. Plus I'm not
sure if xml attributes will maintain line-break characters -- I would
expect they should, but I don't know that as a certainty.
I know WDDX stores queries as a struct of arrays (inverse of this
example), but I never much liked that semantic -- I would much prefer
to see them stored as records probably mostly for the sake of being
human-readable (not that it matters most of the time).
I would say that you have an advantage going to javascript with this
because you can write a reasonably simple page of XSLT to translate
the XML into the appropriate javascript... but since the way you
described it it seems like the client will be deserializing it, that's
maybe not the case. I haven't worked with tranforming or deserializing
XML via a browser, although I've read that browser support for the
standard of XSLT is like browser support for just about everything
else -- which is to say -- garbage.
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket application
http://www.houseoffusion.com/banners/view.cfm?bannerid=48
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169292
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/5
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:5
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.5
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
