Can HTTPRequest return HTML and JS variables?

[Chuck Anderson]

I currently use an HTTP request object (with Php in the server) to
dynamically load HTML into document objects on a page. I do it one of
two ways.

1. I make a request to the server and my Php script returns JavaScript
variables. The returned variables are examined in JavaScript and based
on their value some element (object) on the page is (or is not)
changed. I use what may be a crude method to return variables. Php
echoes a string of the form "var varname1='some value';var
varname2='some other value';". Then in the JavaScript that receives
the HTTP request I merely eval(req.ResponseText). The script can then
make program decisions based on the values of the variables.

2. If a lot of HTML must be inserted/changed, I have the Php script
output the whole block of HTML. Then in the JavaScript that handles the
HTTP request I merely set the appropriate object's innerHTML to
http.responseText (obj.innerHTML = http.responseText).

These two methods have been working well for me.

I find now, though, that I would like to return a block of HTML and some
JavaScript variables via one HTTP request and I can not figure out how
(or if it's even possible) to do it.

(I tried returning the block of HTML as a string variable (converting
all single quotes in the HTML to the html entity "'"), but have had
no luck doing so. I believe that eval can not handle the line feeds.)

The whole point of returning a block of HTML as the http.responseText is
to avoid having to create a lot of complicated HTML within JavaScript
with all of it's necessary escapes (quotes), line feeds, and
concatenation characters. I accomplish this quite nicely with Php and
an included file.

I could simply make two HTTP requests; one to retrieve the variables,
and a second to retrieve the "large" block of HTML, but I thought it
would make sense to try and limit the number of network requests made by
the script.

Is there a method for achieving what I want to do?

Would it make sense to try and return the data in XML format instead of
text - with the HTML block in an XML element - along with any other
variables in heir respective elements?

Or should I merely keep making two requests; one to get variables and
then issue another if I need to retrieve a large block of HTML?

I would appreciate any advice.

TIA

--
*****************************
Chuck Anderson • Boulder, CO
http://www.cycletourist.com
Turn Off, Tune Out, Drop In
*****************************

 

[Carlos JP]

On May 7, 1:08 am, Chuck Anderson <[email protected]>
wrote:
....

2. If a lot of HTML must be inserted/changed, I have the Php script
output the whole block of HTML.  Then in the JavaScript that handles the
HTTP request I merely set the appropriate object's innerHTML to
http.responseText (obj.innerHTML = http.responseText).

I've read here that you shouldn't use the innerHtml, just search inner
innerHtml in the archive.

 

[Jeremy J Starcher]

I currently use an HTTP request object (with Php in the server) to
dynamically load HTML into document objects on a page. I do it one of
two ways.

1. I make a request to the server and my Php script returns JavaScript
variables. The returned variables are examined in JavaScript and based
on their value some element (object) on the page is (or is not) changed.
I use what may be a crude method to return variables. Php echoes a
string of the form "var varname1='some value';var varname2='some other
value';". Then in the JavaScript that receives the HTTP request I
merely eval(req.ResponseText). The script can then make program
decisions based on the values of the variables.

eval("(" + req.ResponseText + ")") tends to work more reliably, if one is
going to use a raw eval. Unless you, personally, have the only and total
control over what is send back, a filtered eval is better.

2. If a lot of HTML must be inserted/changed, I have the Php script
output the whole block of HTML. Then in the JavaScript that handles the
HTTP request I merely set the appropriate object's innerHTML to
http.responseText (obj.innerHTML = http.responseText).

Non-standard, but semi-works. innerHTML has a well-known set of problems.

These two methods have been working well for me.

I find now, though, that I would like to return a block of HTML and some
JavaScript variables via one HTTP request and I can not figure out how
(or if it's even possible) to do it.

Quite possible.

(I tried returning the block of HTML as a string variable (converting
all single quotes in the HTML to the html entity "&apos;"), but have had
no luck doing so. I believe that eval can not handle the line feeds.)

Then don't send line feeds. Either encode them or replace them with
spaces, depending on context. php has a number of nice encoding methods.

The whole point of returning a block of HTML as the http.responseText is
to avoid having to create a lot of complicated HTML within JavaScript
with all of it's necessary escapes (quotes), line feeds, and
concatenation characters. I accomplish this quite nicely with Php and
an included file.

That becomes a lot easier if one gets away from using innerHTML and uses
standard DOM methods. When done properly, the result, IMHO, is much
cleaner.

I could simply make two HTTP requests; one to retrieve the variables,
and a second to retrieve the "large" block of HTML, but I thought it
would make sense to try and limit the number of network requests made by
the script.

Again, depending on context, just include all of the needed HTML from the
get-go. You do have appropriate fall back for users without Javascript?

Is there a method for achieving what I want to do?

You were on the right track, if this is what you want to do.

Would it make sense to try and return the data in XML format instead of
text - with the HTML block in an XML element - along with any other
variables in heir respective elements?

In this case, XML is over-weight and you'd STILL have to encode things
properly. CDATA wouldn't really gain you any advantage.

Or should I merely keep making two requests; one to get variables and
then issue another if I need to retrieve a large block of HTML?

"Depends." No single answer to that.

 

[David Mark]

Do a POST request.


In a GET (which is what you seemed to try), you should encode your
parameters.
<http://www.cs.tut.fi/~jkorpela/forms/methods.html>

Must. And it is the same for POST.

 

[Jorge]

(....)
(I tried returning the block of HTML as a string variable (converting
all single quotes in the HTML to the html entity "&apos;"), but have had
no luck doing so.  I believe that eval can not handle the line feeds.)
(...)

Yes, you can't feed to an eval this:

var innerhtml= "<p>
hi
</p>";

but this is ok:

var innerhtml= "<p>hi</p>";

So, ISTM that you should remove the 0x0d's and 0x0a's in the
reponseText,

e.g.
txt= responseText.replace(/\x0d/g,"").replace(/\x0a/g,"");
eval( "(" + txt + ")" );

HTH,

 

[Chuck Anderson]

On May 7, 1:08 am, Chuck Anderson <[email protected]>
wrote:
...

Lots of good advice .... thanks all.

I've read here that you shouldn't use the innerHtml, just search inner
innerHtml in the archive.

What I read about that was that even listeners will not be cleared when
you set inner.HTML to '' or null, and that can create memory leaks. That
did get me to try and clean up my cat in that regard ... but still ...
I'm going to look more into the DOM methods as mentioned in the next reply.

--
*****************************
Chuck Anderson • Boulder, CO
http://www.cycletourist.com
Turn Off, Tune Out, Drop In
*****************************

 

[Chuck Anderson]

eval("(" + req.ResponseText + ")") tends to work more reliably, if one is
going to use a raw eval. Unless you, personally, have the only and total
control over what is send back, a filtered eval is better.

Okay ... thanks for this tip.

Non-standard, but semi-works. innerHTML has a well-known set of problems.



Quite possible.




Then don't send line feeds. Either encode them or replace them with
spaces, depending on context. php has a number of nice encoding methods.

Something I may or may not still try ... I want to understand what
you've recommended about DOM first.

That becomes a lot easier if one gets away from using innerHTML and uses
standard DOM methods. When done properly, the result, IMHO, is much
cleaner.

Standard DOM methods. I'm not sure what that means, really, but I'll
look into it. My understanding of DOM methods comes from copying
examples and I still have a bit of trouble understanding it all.

Are you talking about creating and deleting child objects or nodes ...
that sort of thing?

Again, depending on context, just include all of the needed HTML from the
get-go. You do have appropriate fall back for users without Javascript?

This particular implementation is for an online card game and I'm making
it easy on myself by requiring JavaScript to use it. I believe it will
be easy to make it work without JavaScript as I am using a form and form
submit buttons with onClick="return(doHTTPRequest())" and making sure
that when I reload a page, it still displays properly (as if the submit
button submitted the form). So yes ... and no (at least for now).

You were on the right track, if this is what you want to do.



In this case, XML is over-weight and you'd STILL have to encode things
properly. CDATA wouldn't really gain you any advantage.

That's kind of how it looked to me.

"Depends." No single answer to that.

Thanks for all the excellent help.

--
*****************************
Chuck Anderson • Boulder, CO
http://www.cycletourist.com
Turn Off, Tune Out, Drop In
*****************************

 

[Jeremy J Starcher]

Jeremy J Starcher wrote:
Standard DOM methods. I'm not sure what that means, really, but I'll
look into it. My understanding of DOM methods comes from copying
examples and I still have a bit of trouble understanding it all.

Are you talking about creating and deleting child objects or nodes ...
that sort of thing?

The term is 'elements' but yes, that is exactly what I mean.

span.innerHTML = '<b>Hello there</b>';


(All code is written off-the-cuff and untested.)

can be re-written as:
deleteChildRecs(span); // You need to supply this function

var e = document.createElement("b");
e.appendChild(document.createTextNode("Hello there");
span.appendChild(e);

You'd do well to read the reference material and it includes some
examples.

https://developer.mozilla.org/en/Gecko_DOM_Reference


Once you understand the concepts of what is happening, you can use some
'wrapper' functions that can simply element creation.

This particular implementation is for an online card game and I'm making
it easy on myself by requiring JavaScript to use it. I believe it will
be easy to make it work without JavaScript as I am using a form and form
submit buttons with onClick="return(doHTTPRequest())" and making sure
that when I reload a page, it still displays properly (as if the submit
button submitted the form). So yes ... and no (at least for now).

IMHO, it is far easier to make something so that it does NOT require
Javascript, then add Javascript to enhance it ... then it is to try and
"work around" the Javascript parts later on.


(Warning: Personal opinion ahead. Tends to draw flames.)
That said, games are one category that I don't mind if they require
Javascript. There is no 'essential information' that is unavailable and
if for some reason, someone can't play a game its not a great loss.

 

[Jeremy J Starcher]

You'd do well to read the reference material and it includes some
examples.

https://developer.mozilla.org/en/Gecko_DOM_Reference

And I'd do well to make sure I include the right URL.

< http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/
core.html#ID-2141741547 >

 

[David Mark]

The term is 'elements' but yes, that is exactly what I mean.

span.innerHTML = '<b>Hello there</b>';

(All code is written off-the-cuff and untested.)

can be re-written as:
deleteChildRecs(span);  // You need to supply this function

var e = document.createElement("b");
e.appendChild(document.createTextNode("Hello there");
span.appendChild(e);

You'd do well to read the reference material and it includes some
examples.

https://developer.mozilla.org/en/Gecko_DOM_Reference

Once you understand the concepts of what is  happening, you can use some
'wrapper' functions that can simply element creation.


IMHO, it is far easier to make something so that it does NOT require
Javascript, then add Javascript to enhance it ... then it is to try and
"work around" the Javascript parts later on.

(Warning: Personal opinion ahead.  Tends to draw flames.)
That said, games are one category that I don't mind if they require
Javascript.  There is no 'essential information' that is unavailable and
if for some reason, someone can't play a game its not a great loss.

Nothing wrong with a game that doesn't work without Javascript,
provided the link(s) to it are created with script. A note for those
who bookmark the game document (and later revisit sans scripting)
would be a nice courtesy (just don't put it in a NOSCRIPT element.)

 

[Jorge]

(...)
Standard DOM methods.  I'm not sure what that means, really, but I'll
look into it.  My understanding of DOM methods comes from copying
examples and I still have a bit of trouble understanding it all.
(...)

See:
An Inconvenient API: The Theory of the DOM:
http://video.yahoo.com/video/play?vid=111582
http://video.yahoo.com/video/play?vid=111583
http://video.yahoo.com/video/play?vid=111584

HTH,

 

[Thomas 'PointedEars' Lahn]

A note for those who bookmark the game document (and later revisit sans
scripting) would be a nice courtesy (just don't put it in a NOSCRIPT
element.)

That is an interesting remark, indeed (although it is following another
mindless full quote[1]). If the NOSCRIPT element is not trustworthy, then
ISTM that a gracefully degrading solution here would require support of a
DOM API capable of preventing elements from being rendered after the
document has loaded.


PointedEars
___________
[1] <http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim>

 

[Jeremy J Starcher]

A note for those who bookmark the game document (and later revisit sans
scripting) would be a nice courtesy (just don't put it in a NOSCRIPT
element.)

That is an interesting remark, indeed (although it is following another
mindless full quote[1]). If the NOSCRIPT element is not trustworthy,
then ISTM that a gracefully degrading solution here would require
support of a DOM API capable of preventing elements from being rendered
after the document has loaded.

The NOSCRIPT element is not trustworthy. In particular, there are some
proxies out there that will strip scripts from the document. The
browser, which has scripting enabled, will not display the contents of
the NOSCRIPT element.

PS:
Just did a quick check of all the proxies I knew that had that problem
and it looks like it has been mostly corrected, but who knows how many
ancient copies are still running on corporate firewalls?

 

[David Mark]

A note for those who bookmark the game document (and later revisit sans
scripting) would be a nice courtesy (just don't put it in a NOSCRIPT
element.)

That is an interesting remark, indeed (although it is following another
mindless full quote[1]).

Glad to be of help.

If the NOSCRIPT element is not trustworthy, then
ISTM that a gracefully degrading solution here would require support of a
DOM API capable of preventing elements from being rendered after the
document has loaded.

That could be interpreted many ways, but I can't come up with one that
makes sense.

 

[Thomas 'PointedEars' Lahn]

That could be interpreted many ways, but I can't come up with one that
makes sense.

..display = "none";


PointedEars

 

[Chuck Anderson]

And I'd do well to make sure I include the right URL.

< http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/
core.html#ID-2141741547 >

Just wanted to say, thanks for the references. I actually found the
Gecko one quite useful (I learned a lot from it) - and the W3 one quite
thorough.

--
*****************************
Chuck Anderson • Boulder, CO
http://www.cycletourist.com
Turn Off, Tune Out, Drop In
*****************************

 

[Chuck Anderson]

See:
An Inconvenient API: The Theory of the DOM:
http://video.yahoo.com/video/play?vid=111582
http://video.yahoo.com/video/play?vid=111583
http://video.yahoo.com/video/play?vid=111584

HTH,

This was excellent. Thank you! I understand the DOM (and how to use it)
much better now.

--
*****************************
Chuck Anderson • Boulder, CO
http://www.cycletourist.com
Turn Off, Tune Out, Drop In
*****************************