> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 15, 2005 9:36 AM
> To: CF-Community
> Subject: Re: Attempt at a WDDX replacement... comments?
>
> 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>
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.
To do this you might have a record set represented as an array of objects:
<data type="array">
<data type="object">
<data type="string" name="fname">blah</data>
<data type="string" name="mname">blah</data>
<data type="string" name="lname">blah</data>
</data>
... LOTS more objects all repeating the same "name"s ...
</data>
Using my original system and making it a bit more complicated it seems like
I could do a "recordset" data type and a "record" member type (or just use
an object data type inside a recordset tag). The recordset would define the
field list and the member would inherit the names from it's wrapper like
this:
<data type="recordset" fields="fname,mname,lname">
<data type="object">
<data type="string">blah</data>
<data type="string">blah</data>
<data type="string">blah</data>
</data>
... LOTS more objects, one for each row returned ...
</data>
All of the records would inherit the field list from the wrapping recordset.
> 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. ;^)
> 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?).
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.
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'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.
> 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.
One of the big things I've not done yet is decide how to escape strings...
the thing about line breaks is a prime example.
When dealing with script you have the "\n" linebreak which doesn't translate
well in other things.... but part of my is just saying I should stick with
the JS escape sequences and let other implementations deal with it.
> 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?
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.
> 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.
Pretty much... I actually don't know XSLT at all so this would be new
anyway. But the impression I get is that even if I new it I would spend
more time fighting with the browsers about it than learning anything useful.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169334
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
