> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 15, 2005 1:07 PM
> To: CF-Community
> Subject: RE: Attempt at a WDDX replacement... comments?
>
> > 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...
Yeah... I'd like to pass recordsets in a meaningful way.
Of course a related problem is that there's really no simple way to pass a
recordset from JS to the server since JS doesn't have the concept (I know I
could create a "recordset" object in JS... but that's pushing things I
think).
But still - in this specific case I need recordsets passed from the server
to the client.
> >> 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. :)
No... of course not. But one idea I have is to extends "fields" to arrays
to allow for sparse arrays.
Something like:
<data type="array" fields="1,5,10">
<data type="string"></data>
<data type="string"></data>
<data type="string"></data>
</data>
Also we get back to the bastard problem of recordsets where I just feel
better keeping the order of the fields. ;^)
> > 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.
But then, it seems, any DTD would need to be that much more complicated,
wouldn't?
I'm new to this stuff... but it seems that describing a single tag with
several optional attributes is a lot easier than describing one tag.
You're code then inherits the problem of integrity, of course... so maybe I
should use tags and put that in the DTD...
I'm back and forth.
> 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...
In my case I definitely have to build the deserializer in JavaScript. I
may also have to take a crack at it in Java... but it would be my first Java
project.
> 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>
Unless I suddenly get a lot more time this won't be using XSL at all...
although it would be nice to learn.
> 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 (I'm arguing an ignorant side here) but it seems to me that
declaring something of "data" and then describing what kind of data is
"cleaner" than just declaring something.
How would a validator know, for example if "<customername>" is a custom data
type or something else? I believe that the values for attributes can be
left ambiguous but tag definitions must be defined, correct?
> 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>
But that creates XHTML - not Option Objects.
In this case I've got, for example, a drop down of "Financial Carrier" and
a related drop down of "Roles". Carriers can only be related to certain
roles and (of course) the reverse is true.
Right now I make two service calls to create collections of option objects
in JavaScript. These options are not displayed on screen, they just exist
as potential screen items.
A third call is made to obtain the possible relationships between the two
fields.
When one of the field is selected the relationship data is referenced and
the appropriate options from the cache referenced (and thus displayed) in
the drop down.
I could have kept the raw xhtml in the collection - but I would still need a
way to reference it and then I would have to use DHTML to add that code to
the display. But that's an implied translation from far text to a JS object
- why do that when you can store the options as a instantiated objects?
> >> 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
But isn't a very CF centric view to adopt (especially in my case where CF
won't even be used in the final application)?
Besides - the external view of a CF query is misleading: internally it's a
struct of arrays (and in most cases you can access it as such).
> 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.
But is there a need to make that distinction to other languages? That's my
point.
Does Java or Javascript need to know that CF has a special structure of
arrays called "query" that looks exactly like an structure of arrays? Or do
they just need to know what do with the data inside it?
Said another way: if I pass down a structure of arrays to javascript I'm
going to have a structure of arrays. How would I react differently to it if
I knew it was a recordset?
I might (to continue my one-sided dialog) turn it instead into an array of
objects (which is more like a "recordset" in my mind and I presume yours).
But if that were the case why not just send down an array of objects? A CF
or Java serializer could do that easily (forgetting, for a moment, the
problem of duplicated data in the XML).
I'm viewing this specifically from the point of view of my current problem:
passing structured data between JavaScript and a server. In general I'm
leaning towards "lowest common denominator" - if JavaScript can't understand
a concept natively I'm not sure it belongs.
> > 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>
With the one exception that the data type is at the column level (which
actually doesn't have to be the case in CF...) I don't see how this is
different from this:
<data type="object" fields="num, name, " >
<data type="array">
<data type="number">3</data>
<data type="number">2</data>
<data type="number">8</data>
</data>
<data type="array">
<data type="string">blah</data>
<data type="string">blah</data>
<data type="string">blah</data>
</data>
</data>
The former is about 4% smaller, to be sure but in practice I doubt that will
matter much (I think the size difference here will pretty much be eliminated
by HTTP Compression in any case).
But what does JavaScript do differently when dealing with the first that
with the second?
I agree completely that changing the type from "object" in my example to
"recordset" may offer a very useful hint to JavaScript (this is the way I'm
leaning).
That hint would simply tell JavaScript to convert this structure of arrays
to an array of structures and nothing more. But it seems that there's no
native way to determine, semantically, if a native JavaScript array of
objects does, in fact represent a recordset for passage back to the server.
I could extend JavaScript with the concept of a recordset - but that seems
to be an unnecessary abstraction since JS doesn't absolutely need to concept
to perform any of the tasks we're talking about.
> 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.)
Well... you'd definitely know better than me.
> 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.
Perhaps... but again, viewing this from a JavaScript-centric perspective
it's just not an issue for me.
It's really nothing I could determine on the JavaScript side of things to
ever pass back to a server.
Server-to-server would be a different story of course... and it might be
nice to expand this to make such a thing simpler (even tho' it has no impact
at all on my current problem).
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Get Instant Hacker Protection, Virus Detection, Antispam & Personal Firewall.
http://www.houseoffusion.com/banners/view.cfm?bannerid=62
Message: http://www.houseoffusion.com/lists.cfm/link=i:5:169379
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=11502.10531.5
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
