> 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).
I dunno... a simple recordset object could be created in probably
10-20 lines... I guess it would depend on what features you wanted to
include... but really, how much is there? ColumnList, RecordCount,
QueryAddRow(), QueryAddColumn(), QuerySetCell() (which might just as
well be omitted in favor of array notation). All of which can be
recreated in ... minutes... Heck, you could probably just grab the
wddx serializers for javascript and make some minor modifications and
be done with it, since iirc they actually did create a javascript
RecordSet class. I'd make RecordCount() and ColumnList() methods and
then expose the columns directly ... so you'd have jsrs.recordCount()
and jsrs.columnList() and to get an individual cell you'd just use
jsrs.nameofcolumn[row]. (I'd make sure all the column names are all
lower case when serialized. As a rule, I'd do this for all variable
names.)
Although even barring creating a class, you could simply declare it as
an object with arrays and declare jsrs._isrecordset as a "reserved
word" variable and use regular javascript operators to get the
columnlist and recordcount (jsrs.columnname.length or for (i in jsrs)
{ clist += ',' + i; } ) ... you'd be able to distinguish the
javascript object from the structure by checking for the existance of
the ._isrecordset variable in the object.
>> >> 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>
Say what? if you've got a fields attribute in the <data> tag when the
type is "array", why would you need <data> tags at all? I must be
missing something... I don't see any reason to have a fields attribute
for an array... And I'm _really_ confused as to how this has anything
to do with the semantic of a structure...
>> > 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.
I'm not sure why one method would require a more complicated DTD than
the other... although in general I recommend against the use of DTD's
.... it's something that really perplexes me that XSD has been a
recommended standard for years now, and yet, everybody is still stuck
on DTD's. Last I checked I still had some problems getting XML Spy to
validate my XSD's when attempting to use the <any-tag> and
<any-attribute> declarations (which I'm probably butchering because I
haven't written an XSD in a long time)... but I'm not sure if that was
a problem with my XSD or with XML Spy -- based on what I read in the
w3c docs for XSD, my guess would be it was a problem with XML Spy. And
if not then we need to address that as a limitation of the standard
for XSD rather than simply falling back on the inferior DTD model.
> You're code then inherits the problem of
> integrity, of course... so maybe I should
> use tags and put that in the DTD...
Would be my recommendation. :)
>> 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.
Yeah, that's going to be harder than XSL pretty much regardless...
Though if you end up doing it in Java, then theoretically you have
XML/XSL parsers already built that can be used... if it has to be
written into an applet that can be run in a browser that may be
interesting, but you may still be able to get away with nabbing code
from Xalan or somesuch.
>> 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.
Well you'd have to define "cleaner"... In XSL in almost (if not all
cases), the XSL for transforming them is cleaner (easier to read) when
it's a tag... Whether or not that's the case with the javascript
deserializer may depend a lot on how the javascript is written. You
may try a google search for XML-Tidy and see if it gives you any
ideas... I've not looked at it myself... just heard about it a while
back in reference to it being used in then future versions of
soEditor. Based on what I've seen of recent wysiwyg's I'm guessing it
or something like it is used in most browser-based wysiwygs now, since
they seem to maintain proper xml formatting when you hit "code view",
enter bad xhtml ("<br>") and switch back.
> 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?
I don't believe that's true... iirc XSD still includes <any-tag> in
addition to <any-attribute> ... Now... once it's in the xsd, what an
individual application does with that information is anybody's guess,
but as an example, I have this blog I just put together, which has
some custom xml in it:
<blog>
<div class="title">%title</div>
<content>
<article>
<div class="article_title">%article_title</div>
<div class="article_text">%article_text</div>
</article>
</content>
</blog>
Although as a whole this is xhtml, I didn't want to put namespaces in
it for the sake of keeping it simple for users who may or may not be
programmers... So... if I wanted I could write an XSD that would
validate this document in spite of the lack of namespaces for the
non-xhtml tags by simply declaring my required tags (blog, content,
article) and then declaring their contents with <any-tag> and
<any-attribute> and that would (in theory) allow the xml to be
validated against the schema even though I haven't explicitly declared
any of tags from the xhtml schema. Then knowing what my tags are, if I
really wanted to, I could write a simple XSL sheet to apply a
namespace of my choosing to the extra tags and also validate the sheet
against the schema for xhtml.
>> 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 think you've lost me...
If you just pass the straight html, then there's a much easier way to
recreate your options for the drop-down in your js...
a couple quick options:
document.getElementById("container").innerHTML = selectHTML;
body = document.getElementsByTagName("body");
body[1].innerHTML += selectHTML;
temp = document.getElementById("tempselect")
document.getElementById("select").innerHTML = temp.innerHTML;
document.removeElementById(temp);
or if you wanted to be even more explicit about it, loop over the
individual options in the select list... but the above 2 are liable to
be significantly more efficient on the client side (the first one in
particular) if you're talking about a lot of options.
>> > 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)?
It's not any more CF-centric than it is Java-centric or
ODBC-centric... Yes, CF has a concept of recordsets, but it's by no
means the only language... and in general I tend to err on the side of
more options.
> 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).
Yeah, and even within JS, it probably makes more sense for it to be an
object with arrays because that's both the way that tables are treated
(more or less) in SQL and the way that columns are referenced in CF
syntax (object.column[row])... the Java or ODBC syntax for referencing
columns is more complicated, but that's a whole other story.
>> 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 would think the distinction may be useful regardless of language,
just because there's no way of _knowing_ how it will be used in the
future. Even if it never goes beyond the javascript, there's always
the potential of some new use in which having it semantically declared
that way may be useful.
> 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.
I'd be hesitant to make that assumption because I think it would be
easier to implement it now than to find a use for it later and then be
trying to reverse-engineer it into the existing system.
>> > 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).
Where are you expecting your bottle-necks to be? ... I wouldn't expect
them to be in HTTP by any means -- I would fully expect the
bottle-necks to be in the deserialization, especially if you're
talking about thousands of records... at which point, I'd expect
verbosity is really an enemy.
As to the data type -- although query columns containing wacked out
data types is kind of a cf-oddity (I believe) using the former
structure wouldn't necessarily elminate it as a possibility... You
could of course omit the type attribute from the column and then place
whatever other data type tags are appropriate within the individual
cell.
> But what does JavaScript do differently when dealing with
> the first that with the second?
JavaScript may not care much -- other than of course with regard to
verbosity...
> 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.
JavaScript doesn't have an explicitely pre-defined mechanism for
declaring it no... but as above, you can simply declare a reserved
variable name and place it in the object to make that distinction if
you're not wanting to create a recordset class.
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:169440
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
