> My first pass had things like that... but when
> getting into recordsets (which I'm still back
> and forth on) things started breaking down.
> If I do that as objects of arrays (as I did in
> the message) then this method works well.
> However if I do them as collections of records
> ("rows") then I'm forced to duplicate the field
> names for every row of the query - perhaps
> hundreds of times.
Yeah, well recordsets are liable to be an issue, and if everything
else works fine that way, then I'd just find a solution you like for
recordsets separately and stick with the more concise script for
everything else...
>> 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.
> True... but when it comes right down to it in some cases
> the order IS relevant. ;^)
Yeah, but not in the context of a struct semantic. :)
>> 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:
> Yeah - I started with that.
> But when it comes right down to it the two just
> aren't that different (it's the old argument that
> all since attributes can be represented as tags
> why have attributes?).
Partly because they're descriptive without adding verbosity... but
then if you're talking about creating an attribute which could be
represented by the tag-name of the tag the attribute is in, then
you're not talking about _adding_ anything really other than
verbosity.
> I think this one is probably more personal
> preference. While it definitely would make
> things a little smaller it's not a huge savings...
> and I still feel (perhaps wrongly) that when
> considering adding data types and such extending
> the possible values of an attribute is easier
> than adding new tags.
I guess it would depend on how you're deserializing the packet, but I
don't think so... at least I know it's not if you're using XSL...
Here's the bit of XSL for either approach:
data tags:
<xsl:template match="[EMAIL PROTECTED]'struct']">...</xsl:template>
varying elements
<xsl:template match="struct">...</xsl:template>
So in this case, using different element names is actually a simpler
solution (unless of course you're like me and you think
case-sensitivity in XML was a stupid decision and try to make all your
xsl case-insensitive):
<xsl:variable name="ucase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />
<xsl:variable name="lcase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:template match="*[translate(name(),$ucase,$lcase)='struct']">
....</xsl:template>
(in which case both approaches are equally complex)
> You could, for example, easily add custom
> data types if you wished. This is generic:
> <data type="object" fields="fname,mname,lname">
> <data type="string">James </data>
> <data type="string">Wilson</data>
> <data type="string">Davis</data>
> </data>
> Could be changede easily to this:
> <data type="CustomerName" fields="fname,mname,lname">
> <data type="string">James </data>
> <data type="string">Wilson</data>
> <data type="string">Davis</data>
> </data>
> With a special handler constructed on both
> ends to do something with "customername" that
> isn't done with a regular object.
I don't really see this being any different or easier than the
tag-name method...
<xsl:template match="[EMAIL PROTECTED]'object']">
<data>
<xsl:copy-of select="@*[name()!='type']" />
<xsl:attribute name="type">CustomerName</xsl:attribute>
<xsl:apply-templates />
</data>
</xsl:template>
or
<xsl:template match="object">
<CustomerName>
<xsl:copy-of select="@*" />
<xsl:apply-templates />
</CustomerName>
</xsl:template>
If anything the tag-name approach is easier at least with XSL...
> I'm not sure if this is useful... but I may
> create a special "optioncache" type (for example)
> that converts it's records directly to JavaScript
> option objects for use in select-lists.
> I'm not sure yet... but I may - and it seems like
> the attribute is more flexible in this regard.
Could be useful... again, I don't see an advantage to having the type
as an attribute in this case... or for that matter there's not really
a need to have it as a separate object type, since you can use an xml
namespace to declare the content as raw xhtml:
<my-custom-xml-stuff>
<select name="blah" xmlns="http://www.w3c.org/yadda/xhtml";>
<option value="blah">...</option>
<repeat ... />
</select>
</my-custom-xml-stuff>
>> 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 go back and forth... I can see the logic of both.
> So, in general I'd like to support both.
> My main problem with recordsets is that they can
> be represented by simpler objects:
> 1) An object whose named-properties are arrays
> representing each column.
> 2) An array whose indexed fields are objects
> representing each record.
> So, considering that, do I really need a special
> "recordset" tag at all?
Yes.
Although they can be represented by other objects, they are not
semantically the same... That is... to CF, an array of structs or a
struct of arrays, while it may contain _exactly_ the same data as a
query is absolutely _not_ a query. If your xml doesn't also make that
distinction, then there won't be any way to differentiate on the
receiving end between an object which is semantically a recordset and
an object which is semantically a structure of arrays.
> Even when we talk about field lists it seems
> like generic objects with predefined fieldlists
> to reduce duplication (using some sort of
> "<fieldset>" tag to define them and a "fieldset"
> attribute to reference them) seems best.
Okay, I'll buy that... and given a necessity for mechanical
efficiency, I'd even be willing to represent the query as a struct of
arrays rather than an array of structs in spite of my distaste for the
semantic... deserializing a query of thousands of records using
JavaScript is never going to be efficient, so in this case every
little bit helps...
<recordset name="myrecordset">
<column name="num" type="number" precision="10" scale="2">
<cell value="3" />
<cell value="2" />
<cell value="8" />
</column>
<column name="name" type="string" length="50">
<cell>blah</cell>
<cell>blah</cell>
<cell>blah</cell>
</column>
</recordset>
In addition to my semantic preference, I would also suggest that this
is better than using a comma-delimited "fields" attribute also because
XSL doesn't handle comma delimited lists gracefully... at least not
yet... It's like using them in database columns -- there are things
you can do with them, but it's limited and ugly. I actually wish I'd
known this sooner myself. (This may not be the case with more recent
xsl engines, but it's been my experience with the xsl engine that
ships with CF.)
It actually may be important (or useful) for the sake of recordset
data to define even more precise data types than the remaining dialect
for the sake of later potential db replication. Not that this is
necessarily likely, but I would think having it as a potential option
wouldn't be a bad thing.
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Purchase Studio MX with Flash Pro from House of Fusion, a Macromedia Authorized
Affiliate and support the CF community.
http://www.houseoffusion.com/banners/view.cfm?bannerid=51
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169339
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
