> -----Original Message-----
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 15, 2005 6:07 PM
> To: CF-Community
> Subject: RE: Attempt at a WDDX replacement... comments?
>
> > 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
It's not that it's difficult - it's a matter of forcing data use in your
client-side program based on your transport mechanism and server-side
software... that just seems wrong to me.
Not difficult at all... it just doesn't feel right. Now, of course, you
could still create a custom "RecordSet" object and pass it using this
dialect... but using the dialect shouldn't force decisions on you in other
areas. I think.
> 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...
It has nothing to do with a struct, but it has everything to do with
JavaScript and a <data> tag.
The "fields" attribute is a generic term which always refers to the index
labels of the member data. For object/structs this is list of property/key
names. For normal arrays this is just consecutive numbers
(1,2,3,4,5,6,7...). But we assume that unless told otherwise arrays are
always numerically consecutive (not sparse) and don't require it to be
explicitly stated.
However for Sparse arrays the numbers aren't in sequence. So the fields
could be something like "4, 14, 534". You couldn't really send such an
array using this (or WDDX) since you'd have to send 534 <data> tags with all
but three of them being null. This isn't the same thing however.
To be explicit consider this (perfectly legal) JavaScript array:
A = new Array();
A[20] = "15";
A[34] = "foo";
A[159] = true;
This might be represented in my dialect as:
<data type="Array" fields="20,34,159">
<data type="number">15</data>
<data type="string">foo</data>
<data type="number">true</data>
</data>
Now I'm not sure WHY you'd need something like that (I'm sure somebody has
done it someplace, sometime)... but you could pass it.
In general the fields attribute is only useful to objects. But it could be
used as shown to deal with sparse arrays.
> > 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:
I think dealing with the options as objects is a LOT easier...
MyOptions = new Array();
MyOptions[1] = new Option("Jim");
MyOptions[2] = new Option("Carol");
MyOptions[3] = new Option("Paxton");
MyOptions[4] = new Option("Matilda");
document.forms[0].mySelect.options.length = 0;
for(Cnt=0; Cnt < MyOptions.length(); Cnt++) {
document.forms[0].mySelect.options.options[Cnt] = MyOptions[Cnt];
};
You could, of course add custom properties to the option objects to make
determining which to display easier... something like this:
MyOptions = new Array();
MyOptions[1] = new Option("Jim");
MyOptions[1].gender = "m";
MyOptions[2] = new Option("Carol");
MyOptions[1].gender = "f";
MyOptions[3] = new Option("Paxton");
MyOptions[1].gender = "m";
MyOptions[4] = new Option("Matilda");
MyOptions[1].gender = "f";
document.forms[0].mySelect.options.length = 0;
for(Cnt=0; Cnt < MyOptions.length(); Cnt++) {
if (MyOptions[Cnt].gender == "m" ) {
document.forms[0].mySelect.options.options[Cnt] =
MyOptions[Cnt];
};
};
You can also make option objects members of complex objects that related to
them or vice versa - so instead of "gender" about I could have just created
a reference to an instantiated "person" object.
Lastly since you're using the same option objects for your displays
(assuming, as I do, you cache them locally) you get a tiny performance
increase (since the options are already instantiated) but also built in
"form memory" since setting the "selected" attribute of an option can
persist to the next time you use the option.
You can also throw options willy-nilly amongst different select boxes (this
makes related selects much simpler) and the like.
> > 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.
True... but in this case I'm leaning towards KISS more than anything else.
I see nothing in my dialect, as it is, that wouldn't ALLOW for the addition
of a dedicated recordset object... however I also see no immediate use for
it to my current need.
> > 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.
To add it to the dialect wouldn't require any sort of reverse engineering I
would think. It's just an addition.
Existing apps could use it (in which case there would be work) or not (in
which case there wouldn't be any work - they would just continue on as
before).
By the same token I've no need for a "binary" data type right now and may
never need one - but it could be added easily.
> 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.
I don't think that transfer speed for this app will be a problem. I also
don't really expect deserialization to become an issue for me personally.
JavaScript's not the faster beast in the jungle but it does sit there with
100% of a modern machine at its disposal.
Even with thousands of records (which I won't have) I don't think it would
become a serious issue (slow, yes, but too slow... probably not).
> > 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.
It's where that would happen I suppose. At least for me I've fond no need
to send recordsets UP from JavaScript - just down to it so this is probably
just an intellectual exercise...
But still, I'm having trouble seeing a good reason for a solution which is
being created soley to pass data to and from JavaScript to force the
language to change... it seems more appropriate to me for the server-side to
change to meet JavaScript's idiosyncrasy's in this case.
But I could always be wrong... there is a first time for everything. ;^)
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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:169471
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
