Nobody likes to be called a dummy by a dummy.

GENIUS

What he is saying is against the current developments.

Instead, XmlHttpRequest will be replaced by a protocol that has one more abstaction layer, namely SOAP, as everything will become webservices.

On the other hand, the parsing and validation is not important at all, as it happens on the client, where the processor is totally bored, even when it is playing videos in the background.
Permalink Erik Springelkamp 
January 19th, 2006
that's fine but I can use this for my project as is and save a hell of a lot of time.

If it breaks later, I'll refactor. :)
Permalink Mark Warner 
January 19th, 2006
Seriously I don't understand the need to wrap web RPC in layer after layer of abstraction. It seems like it's simply to give geeks something to do.

What he's proposing is quick, lean, and perfect.
Permalink Mark Warner 
January 19th, 2006
And it is custom made.

You might as well design your own binary protocol for maximum efficiency, effectively making an old fashioned terminal of your web application.

But today relational databases can return their result sets directly in xml, and when your application can use that output, you don't need custom server processing.

It all depends on the size of the organization.

When you are the sole designer, you can do whatever you like. When you work in a team you must choose a protocol, and you might as well choose a protocol everybody knows.

When your application shared with multiple organisations, using different platforms, you better choose a well established protocol.
Permalink Erik Springelkamp 
January 19th, 2006
custom made? He's returning pure javascript in response to an XMLHttpRequest, which is written in JAVASCRIPT, which I'm pretty sure he didn't invent.
Permalink Mark Warner 
January 19th, 2006
Oh I get what you're saying.

But what the fuck do I care if my XML request (let's say I use SOAP) can call YOUR webservice or not? I wrote it for MY webservice and the possibility of your service even being able to correctly understand the request (even in a standard format) is nill.
Permalink Mark Warner 
January 19th, 2006
Even when you choose an open protocol your partners will fuck up anyway, but I rather point them to a w3c specification (or a MicroSoft design pattern) than trying to defend my own contraption.
Permalink Erik Springelkamp 
January 19th, 2006
I think generating a javascript response is as expensive on the server as generating xml.

Probably more expensive, as modern xml tools are highly optimized. I foresee special xml-hardware processors like we have numerical processors.

Our organization just bought some xml-firewalls from DataPower that are completely optimized for xml-processing and PKI-cryptography. Their throughput is enormous, and the backend can go right on with the businesslogic.

A few months ago IBM launched it's new big iron with a PKI hardware unit that can process 1 billion secure xml transactions per day.
Permalink Erik Springelkamp 
January 19th, 2006
I don't think you'll save very much server CPU by generating javascript instead of XML, no. I DO think you'll save bandwidth (whoopie) and you'll definitely save CPU time on the client (which probably doesn't need saving).

Most importantly, I think, is saved development time. Instead of writing code to create and then copewith xml, I just generate script and the only code to write client side is eval(string) :)
Permalink Mark Warner 
January 19th, 2006
Why would you save development time when you put script in the xmlrequest instead of putting it in the original webapp?

Why would you save bandwith when you transmit code with your data each time instead of one time when you load the appplication?

Plus it is an unwanted entanglement between server requests and client rendering.

But as a single developer you can do whatever you like :-)

Just look at the power of xpath before inventing the wheel
Permalink Erik Springelkamp 
January 19th, 2006
Because, doofus, I have to write the javascript code to actually perform the work either way.

However, if I put raw javascript in the reply to XMLHttpRequest, then I save myself writing:

function = DocumentElement.ChildNodes[0].value;
params  = DocumentElement.ChildNodes[1].ChildNodes;
call_user_func(function, params);
...
...
...


I can just write eval(responseText);


Wheeeeee
Permalink Mark Warner 
January 19th, 2006
"When your application shared with multiple organisations, using different platforms, you better choose a well established protocol."

Of course, in the web environment this is all moot because the client can only contact the same domain as the original page. Therefore you really can only have one organization and likely only one platform.

I think XML is an excellent interchange format (self-documenting) but it's horribly bloated. I know that people are now generating there entire website as XML and then XSLT'ing it to HTML -- I never understood the point of that!
Permalink Almost H. Anonymous 
January 19th, 2006
Yes one can use responseText instead of responseXML. Someone mentioned transmitting data as inited JavaScript array statements (which does seem like overkill).

Don't forget - you can gzip your HTTP responses and mark them as Content-Encoding: gzip and the client will unzip them for you for free. (That's something a little mod_perl code is real good at.)
Permalink slava 
January 19th, 2006
"function = DocumentElement.ChildNodes[0].value;
params = DocumentElement.ChildNodes[1].ChildNodes;"

You shouldn't use ChildNodes[0], because you might get insignificant whitespace, and it is not selfdocumenting.

use
ParametersNode = OldNode.selectSingleNode("MyParameters")
Permalink Erik Springelkamp 
January 20th, 2006
Where the fuck is all this documented even close to well??? I see lots of tuts with bits and pieces of DOM but no end-to-end tutorial or even a reference that's not written in Klingon.
Permalink Generic Error 
January 20th, 2006
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/

This is it. It is complete, it is the definition.

It's a bit formal to read, but it is precise and you don't suffer from interpretations or simplifications from a tutorial.
Permalink Erik Springelkamp 
January 20th, 2006
Yeah I tried to read that and got cross-eyed after a few pages.

I guess I need to find a good book.
Permalink Generic Error 
January 20th, 2006
The energy put into understanding this w3c paper is well spent. You can read the next one much quicker, as they are all written in the same formalized language.

It's something I learned from my science carrier: always go for the original papers, don't waste your time on intermediaries.

I wish MicroSoft engineers would do it, then we would have components that would actually conform to the standard.
Permalink Erik Springelkamp 
January 20th, 2006
"I think XML is an excellent interchange format (self-documenting) but it's horribly bloated. I know that people are now generating there entire website as XML and then XSLT'ing it to HTML -- I never understood the point of that!"

How else would you propose to present the text to the screen? Maybe I'm missing something here.

I hate XSL/T, but it is useful for controlling the layout. Going direct to HTML and skipping transformation/xsl means wrapping script code into your HTML.
Permalink sharkfish 
January 20th, 2006
What's wrong with that? It's called templating. Why do you need to have a script pump out an intermediate transport format that is then IMMEDIATELY translated into another format for viewing? What's the benefit?

The only benefit I can see is if you want to also have another process that can hook in between and grab the raw XML before it's styled in order to "scrape the screen" and load the data into some other workflow or process. How often would you need to do something like that at that particular stage? I can't think of any instances, personally.
Permalink Generic Error 
January 20th, 2006
" What's wrong with that? It's called templating. "

I'm confused now. When I retrieve a string of text via xmlhttprequest, I present it to the user in some format they can immediately understand with visual/layout.

I can use say, a "tag" framework to assist me, but I have to flip that text into a format the framework understands in order to do so.

For example, to bind text to a datagrid or table, you can put it into an array or arraylist. But the response object in xmlhttprequest is just text. So now I have to convert the text into a collection the framework understands so I can bind it to the datagrid/table.

Alternatively, I can loop through the response text and stick HTML tags in between the string values to build an HTML table.

BUT if my response is XML and not just plain text...

Or I can just transform the response using XSL/T. That's why XML is useful in this regard.

Now that I've stated the obvious, I can ask the question, what's the big deal? Either way, it's a pain in the ass.

You're either maintaining XSL and stylesheets, or you are maintaining scripts that loop through text and stick HTML in between to format it.

Maybe I missed something here? I am PMSing, so I am stupider than usual.
Permalink sharkfish 
January 20th, 2006
"Or I can just transform the response using XSL/T. That's why XML is useful in this regard. "

Should be

"THEN I can just transform the response using XSL/T. That's why XML is useful in this regard. "
Permalink sharkfish 
January 20th, 2006
Wait are you talking about using XSLT to format an XML response from an XMLHttpRequest request? Because I got the impression from AA that he was talking about building the entire site from XML in the first place and then XSLT'ing it into an HTML page, with XMLHttpRequest completely aside the point...
Permalink Generic Error 
January 20th, 2006
"However, if I put raw javascript in the reply to XMLHttpRequest, then I save myself writing:

function = DocumentElement.ChildNodes[0].value;
params = DocumentElement.ChildNodes[1].ChildNodes;
call_user_func(function, params);
...
...
...


I can just write eval(responseText);"


This just seems messier to me than pulling through XML using responsexml and binding it to a tag/framework table/dropdown box/radio buttons blah blah or doing a custom thingie with XSL.

But then, I like leaky abstractions. I don't get paid to be brilliant.
Permalink sharkfish 
January 20th, 2006
"Wait are you talking about using XSLT to format an XML response from an XMLHttpRequest request? "

Yes.
Permalink sharkfish 
January 20th, 2006
Ah then you've missed the point, I think. :)

I don't know dick about XSLT, and I don't think it'll suit my purpose using XUL anyhow. :)

I'm going with the javascript "solution", and if it breaks in future builds of FF I'll deal with it then. I plan to build my code independant of the server request method, so that if I have to refactor I'll just unplug the javascript business and plug in something else.
Permalink Generic Error 
January 20th, 2006
Your enthusiasm is contagious. Now I have to look up XUL. Dammit.
Permalink sharkfish 
January 20th, 2006
:D
Permalink Generic Error 
January 20th, 2006

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: January, 2006 Other topics: January, 2006 Recent topics Recent topics