How do I get HTML sent to server?

[MC]

Hey,

I have a need to get HTML from a client back to a server to do server
processing. I would like the HTML and form data both. Is there a simple way
to capture that? I do not want to submit the page...I will use ajax to send
the data.

I know how to get the elements but not the entire page or form. I am really
just interested in specifying document.form2 and sending that.

Thanks,
Mica

[SAM]

MC a écrit :

Hey,

I have a need to get HTML from a client back to a server to do server
processing. I would like the HTML and form data both. Is there a simple way
to capture that? I do not want to submit the page...I will use ajax to send
the data.

I know how to get the elements but not the entire page or form. I am really
just interested in specifying document.form2 and sending that.

I do not understand why you need the html ...
Simplest being to submit the form2 using Ajax, then on response, to
populate the fields (or to replace the whole content of form2).

--
sm

[MC]

"SAM" <st*********************@wanadoo.fr.invalidwrote in message
news:48*********************@news.orange.fr...

MC a écrit :

>Hey,

I have a need to get HTML from a client back to a server to do server
processing. I would like the HTML and form data both. Is there a simple
way to capture that? I do not want to submit the page...I will use ajax
to send the data.

I know how to get the elements but not the entire page or form. I am
really just interested in specifying document.form2 and sending that.

I do not understand why you need the html ...
Simplest being to submit the form2 using Ajax, then on response, to
populate the fields (or to replace the whole content of form2).

--
sm

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

[Jonas Raoni]

On Sun, 15 Jun 2008 17:57:11 -0300, MC <"mica[removethis]"@aisus.com>
wrote:

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Strange. If you want the *exactly* HTML sent back to your server, you
should not use "innerHTML" (the browser may output it the way it wants),
instead store (at server-side time) a copy of the HTML that must be sent
back somewhere (hidden input, JavaScript variable, [...]) and when sending
your form, grab that content.
--
Jonas Raoni Soares Silva
http://jsfromhell.com

[MC]

"Jonas Raoni" <jo********@gmail.comwrote in message
news:op.ucte9vdlrwisdc@jonasraoni...

On Sun, 15 Jun 2008 17:57:11 -0300, MC <"mica[removethis]"@aisus.com>
wrote:

>Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Strange. If you want the *exactly* HTML sent back to your server, you
should not use "innerHTML" (the browser may output it the way it wants),
instead store (at server-side time) a copy of the HTML that must be sent
back somewhere (hidden input, JavaScript variable, [...]) and when sending
your form, grab that content.
--
Jonas Raoni Soares Silva
http://jsfromhell.com

Ok, again, the library wants the entire content to process. It will make an
archive of the page the way the client sees it with their form data added.
Does anyone know how to do this?

MC

Mica

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

Ok, again, the library wants the entire content to process. It will
make an archive of the page the way the client sees it with their form
data added. Does anyone know how to do this?

Who is the boss, you the programmer or the library?
If you do not like a library function, write your own alternative one.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[SAM]

Evertjan. a écrit :

MC wrote on 16 jun 2008 in comp.lang.javascript:

>Ok, again, the library wants the entire content to process. It will
make an archive of the page the way the client sees it with their form
data added. Does anyone know how to do this?

Who is the boss, you the programmer or the library?
If you do not like a library function, write your own alternative one.

True but :
that doesn't explain to me how it is possible to submit the html ... ?!
(I thought it needs ftp)

What I do not understand : certainly somebody or something did create
the html, so it is most than probable that the html file must exist
somewhere (or can be saved somewhere).

--
sm

[Evertjan.]

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Evertjan. a écrit :

>MC wrote on 16 jun 2008 in comp.lang.javascript:

>>Ok, again, the library wants the entire content to process. It will
make an archive of the page the way the client sees it with their
form data added. Does anyone know how to do this?

Who is the boss, you the programmer or the library?
If you do not like a library function, write your own alternative
one.

True but :
that doesn't explain to me how it is possible to submit the html ...
?! (I thought it needs ftp)

You can send any string to the server using form post.
HTML is just a text string.

What I do not understand : certainly somebody or something did create
the html, so it is most than probable that the html file must exist
somewhere (or can be saved somewhere).

If you mean the html of a web page, that either exists on the server as
a file or is made on the spot by serverside script. And the received
html is probably stored in the client browser cashe, but that file is
not available to clientside script, only through the browser's
view-source menu, or you can search for it by hand on your computer.

So why not "get" it from the server using xmlhttp. You can even, with
serverside scripting, have called by the server any page on the web, so
also pages on the own server, without involving the client, other than
that the clinet initiates that script.

If, however, you mean "the html" on the client browser [posweebly after
the client has manipulated it by inserting strings, or by clientside
script], that does not exist, as the visualisation is stored in the DOM
tree, a kind of relational database, and if you call innerHTML of the
body, a new and certainly different html is [re]constructed from the DOM
tree, and most of the <headpart is usually not reconstructed.

===========

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[SAM]

Evertjan. a écrit :

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Thanks for the given light, but I'm not the OP :-)

--
sm

[Evertjan.]

SAM wrote on 16 jun 2008 in comp.lang.javascript:

Evertjan. a écrit :

>SAM wrote on 16 jun 2008 in comp.lang.javascript:

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Thanks for the given light, but I'm not the OP :-)

Oh, sorry.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[MC]

Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

MC

[Lasse Reichstein Nielsen]

"MC" <mica[removethis]@aisus.comwrites:

Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

>

>Anyway, I repeat myself, your "need" is only due to a illogical
slavery on your part to your library.

[please do not quote signatures on usenet]

This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[MC]

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn*******************@194.109.133.242...

MC wrote on 16 jun 2008 in comp.lang.javascript:

>>

>>Anyway, I repeat myself, your "need" is only due to a illogical
slavery on your part to your library.

[please do not quote signatures on usenet]

>This is not an illogical slavery. The library is GREAT.

Wow, GREAT if you say so! I do not believe so.
That just means you are a willing slave to that greatness.

>Everybody is

I wouldn't think everybody, as you did not ask or hear evrybody.
Are you a man or woman of superlatives?

>hung up on why I want to do this and not the how.
DOES ANYONE KNOW HOW???

You cannot do this and you should not want to do this.
Wanting to do what is impossible is nice, but not productive.

>The why, is I want to construct an archival image of the view a user
sees in a client browser.

1 html does only approximately show how different browsers, different
sizes
and different OS'es show a window.

2 html is available on the server and can be directly taken from the
server
by xmlhttp.

3 html does not show the changes made to the DOM on the browser.

[I wrote all these arguments before in this thread]

>This library can be used to construct an
encrypted page view image while maintaining inner data and it is
easily renderable while encrypted by most browsers.

Impossible, if you mean "image" like most of us do.

What is "inner data", html being html?

What is "renderable" in the sense of a browser, a browser does not render
html, as html is the source as far as the browser is concerned?

What browser "encripts" the html?
Or do you mean parsing the html source to the DOM?

>The archival image
will be used as a legal construct to document what a user saw in the
browser and may be used in court.

You must have a very naive judge to believe such.

> Web sites do not come from a single
server so reconstructing what the server serves is inappropriate as
the client view may get content from dozens of servers to build a
single client view.

Could be true, but that is immaterial, only using clientside in-browser
javascript scripting.

You would need to conserve a screenview or a windowview, quite possible
with a seperate programme, but not just with browser scripting.

And even so, such view can be easily manipulated, so would not do for
juridical proof.

========================================

Remember you asked:
"How do I get HTML sent to server?"
[Which server, btw, since now you stipulate several servers?]

And not:
"How do I send a screenview to the server ?"

And I showed "sending html to a server" to be inappropriate for conserving
the view the user has seen on his or her screem.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Look,
This is not helping and its not constructive. Yes, the main html is served
by a single page but the inner content may come from dozens of servers. We
are trying our best to approximate and document the client view. And yes, I
can construct an encrypted image that is comprised of data elements using
this library. I don't care if you have a problem with that. The how is what
I am interested in. It seems that if you can't offer a solution, then the
problem is criticized. I thought pointy ears was the only one being
unfriendly in that manner here.
MC

[MC]

"Lasse Reichstein Nielsen" <lr*@hotpop.comwrote in message
news:pr**********@hotpop.com...

"MC" <mica[removethis]@aisus.comwrites:

>Because a 3rd party server library requires it for processing just as it
looks completed on the client browser.

Sending the HTML won't give you that. It only gives you the structure
of the HTML, not what it *looks* like when displayed in a browser.
For that, you need a screenshot.

If you insist on converting the page's document structure back to HTML
and send that back to the server (including user-entered values in
form controls), you'll have to traverse the DOM structure and build
the HTML.

The non-standard innerHTML property only reads the original value
of input controls (i.e., "inputControl.originalValue", not the currently
entered value, "inputControl.value"). I.e., it misses the user entered
values.

This means that the HTML you generate is not what is currently being
shown, but *your* conversion of the DOM objects into a text
representation. If you are doing that anyway, why not just send
the values and build the structure on the server side.

Or, if you really, really need to be sure what the user sees,
accept his values as a normal form submit, and then generate
a bitmap image displaying those values along with a secret word,
and have the user submit the secret word to confirm that he
agrees with the data in the image.
That way you know what image was displayed, and that he can see
images.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors:
<URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

THANK YOU!
I appreciate someone trying to help rather than criticize!

Just sending the data back will not work, as the client view may have html
content from other sources in its view.

I understand that a screenshot would work...any ideas on sending one back to
the server based on a .js event? I would really prefer to have a data image
as I can encrypt that and still retrieve the data from it. This will allow
me to pull data from it and index it to a database while storing the image.
The image does not need to be perfect as a client view but as good as
possible.

Is there any way to traverse and build the HTML and get the user entered
data? This is the real question no one seems to be able to answer.

MC

[david.karr]

On Jun 16, 7:43 am, "MC" <mica[removethis]@aisus.comwrote:

The why, is I want to construct an archival image of the view a user sees in
a client browser. This library can be used to construct an encrypted page
view image while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court. Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

Other posters have been making this point, but if you need to store
exactly what was viewed, storing the HTML will not do that, even if
you could accomplish that.

You might consider encapsulating the "legal" information into PDF and
archiving that. That would be a more reliable rendering of what "they
saw", because PDF rendering is less variable between browsers.

[Evertjan.]

MC wrote on 16 jun 2008 in comp.lang.javascript:

This is not helping and its not constructive.

Showing you the errors of your thought must be constructive and helpful,
even if you do not like the answer.

On usenet, you can ask questions, but you can not dictate the answers.

Yes, the main html is
served by a single page but the inner content may come from dozens of
servers.

A strange way to define "inner content of html".

The page as shown in a browaser window can have inner content in an
iframe or as a change in the DOM. but that is not part of the html.

You could reconstruct a form of html from the DOM, using innerHTML,
but it would not do the job and certainly not convince the judge.

We are trying our best to approximate and document the client
view.

I showed you it was impossible to do, using a send back of html.

And yes, I can construct an encrypted image that is comprised of
data elements using this library. I don't care if you have a problem
with that.

I is not about if you care or do not.
I seem to remember you are the asking party.

The how is what I am interested in. It seems that if you
can't offer a solution, then the problem is criticized. I thought
pointy ears was the only one being unfriendly in that manner here.

You are just incontent with the answer,
because it does not follow your preconceived ideas.

Not liking my answer does not change the fact
that if it is impossible, it just is.

How are you so sure it is possible?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[VK]

On Jun 16, 9:57 pm, VK <[e-mail]:

The problem is that the browser - any browser - does _not_ have access
to the HTML source used to render the current page. Yes, sounds crazy.
Yes, anyone can click View Page Source or equivalent to see the
source: anyone can but browser cannot. What browser can "see" is the
DOM Tree resulted from the parsing algorithms and error correction
mechanics of this particular browser applied to the server HTML
source. Respectively by getting document.documentElement.innerHTML
(the whole page) or document.body.innerHTML (body only) you are not
getting the original source. Instead the browser is "reverse
engineering" for you the current DOM Tree into some HTML code which
is, being reused by this particular browser, should result to a copy
of the current DOM Tree which is by itself is a browser-specific
result of parsing the original HTML source.

This is why btw the infamous Gecko's "phantom nodes" bug #26179
https://bugzilla.mozilla.org/show_bug.cgi?id=26179
remains a sample of unjustified silliness and stubbornness: because it
fights for a careful preservation of sorry leftovers of something that
doesn't exist in the browser's runtime nor accessible from within the
browser.
Someone just wanted to save its time on parse-adding extra spaces in
text/plain paragraphs like
<p>Lorem ipsum
dolor sit amet</p>
and to justify its laziness he brought W3C, traditions, standards and
nearly the Lord himself as a witness to prove himself right. :-\ :-)
An old story but still upsetting and still seriously influencing to
many coding paradigms...

[SAM]

MC a écrit :

>Anyway, I repeat myself, your "need" is only due to a illogical slavery
on your part to your library.

Evertjan,

This is not an illogical slavery. The library is GREAT. Everybody is hung up
on why I want to do this and not the how.

I think you'll have to copy-paste(*) all the DOM in an hidden field sent
to the server when submitting (or on leaving the page).
But it's the user who decides to send that. Will he do it ?

DOES ANYONE KNOW HOW???

Evertjan told +/- how to do a copy, but certainly not how to receive it
without user's agreement.

The why, is I want to construct an archival image of the view a user sees in
a client browser.

I do not understand
(how to get a snapshot of the screen on the user's PC?)

This library can be used to construct an encrypted page view image

by 'image' you mean a picture ?
or just a representation (some code to show the expected view)

while maintaining inner data and it is easily renderable while
encrypted by most browsers. The archival image will be used as a legal
construct to document what a user saw in the browser and may be used in
court.

??? really ? are they mad ?

How do you reflect what did NC4 saw and what did Fx 3 or IE 8 ?
(NC4 doesn't know the DOM, IE 5 or 6 do what they want, no activeX on
Mac, and so on (plug-ins, java ... etc))
What about JS and Ajax (how to know if the user pressed this or this
button launching an XHR function that modified the page?)

But perhaps you want to illustrate what your server send to users ?
Why not to do the snapshots (for each environment and browser) by yourself?
<http://browsershots.org/>

Web sites do not come from a single server so reconstructing what the
server serves is inappropriate as the client view may get content from
dozens of servers to build a single client view.

You forget Ajax, Flash and certainly more.
An image will not show the hidden javascript nor what the Flash can do.

(*) the copy-paste of DOM isn't so easy
it seems to be the alone way because the DOM of a displayed page
can be modify at any time, changing the view

The real question is : how to get it, if the user doesn't send it.

--
sm

[SAM]

MC a écrit :

>
Just sending the data back will not work, as the client view may have html
content from other sources in its view.

how that could be possible ?
Didn't you send the original html code ?

I understand that a screenshot would work...any ideas on sending one back to
the server based on a .js event? I would really prefer to have a data image
as I can encrypt that and still retrieve the data from it.

getting the image to data can be made on server, that is not the problem

it is :
- to realize a snapshot at the user
- to send back this snapshot
two operations impossible in JS

Is there any way to traverse and build the HTML and get the user entered
data? This is the real question no one seems to be able to answer.

<http://stephane.moriaux.pagesperso-orange.fr/truc/innerHTML_danger>

As told you'll have to get all parts of the DOM while translating them
in html without forgiving the content of forms's fields and other
attributes of the tags and to put all that code in an hidden field sent
with the form.
But this method (if it works) will not allow you to assure the user did
really saw what you or I will see with this code.

The only possibly available method is to send back a PDF view of same
html served with the form completed with what was sent back by the form,
for agreement by user.

And what about certificates ?

What about forms in PDF ?
(I don't know how to send back a filed pdf form)

--
sm

[MC]

Sam,

The user will always initiate the archival action. They will complete the
form, then press print. At that time, the print method will be called and
the data sent via ajax back to the server to make a copy.

The image does not have to be exact to be a legal copy only the best
approximation available.

MC

[Evertjan.]

SAM wrote on 17 jun 2008 in comp.lang.javascript:

MC a écrit :

>>
Just sending the data back will not work, as the client view may have
html content from other sources in its view.

how that could be possible ?
Didn't you send the original html code ?

>I understand that a screenshot would work...any ideas on sending one
back to the server based on a .js event? I would really prefer to
have a data image as I can encrypt that and still retrieve the data
from it.

getting the image to data can be made on server, that is not the
problem

it is :
- to realize a snapshot at the user
- to send back this snapshot
two operations impossible in JS

>Is there any way to traverse and build the HTML and get the user
entered data? This is the real question no one seems to be able to
answer.

<http://stephane.moriaux.pagesperso-orange.fr/truc/innerHTML_danger>

As told you'll have to get all parts of the DOM while translating them
in html without forgiving the content of forms's fields and other
attributes of the tags and to put all that code in an hidden field
sent with the form.
But this method (if it works) will not allow you to assure the user
did really saw what you or I will see with this code.

The only possibly available method is to send back a PDF view of same
html served with the form completed with what was sent back by the
form, for agreement by user.

And what about certificates ?

What about forms in PDF ?
(I don't know how to send back a filed pdf form)

SAM your advice is sound, however ...

Perhaps the OP could ask the user to buy a digital camera and take a shot
of the monitor screen, and then send that image over to the server?

The subject is: "How do I get HTML sent to server?".

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[beegee]

On Jun 17, 5:57*am, "Evertjan." <[e-mail]:

SAM wrote on 17 jun 2008 in comp.lang.javascript:

MC a écrit :

Just sending the data back will not work, as the client view may have
html content from other sources in its view.

how that could be possible ?
Didn't you send the original html code ?

I understand that a screenshot would work...any ideas on sending one
back to the server based on a .js event? I would really prefer to
have a data image as I can encrypt that and still retrieve the data
from it.

getting the image to data can be made on server, that is not the
problem

it is :
- to realize a snapshot at the user
- to send back this snapshot
two operations impossible in JS

Is there any way to traverse and build the HTML and get the user
entered data? This is the real question no one seems to be able to
answer.

<http://stephane.moriaux.pagesperso-orange.fr/truc/innerHTML_danger>

As told you'll have to get all parts of the DOM while translating them
in html without forgiving the content of forms's fields and other
attributes of the tags and to put all that code in an hidden field
sent with the form.
But this method (if it works) will not allow you to assure the user
did really saw what you or I will see with this code.

The only possibly available method is to send back a PDF view of same
html served with the form completed with what was sent back by the
form, for agreement by user.

And what about certificates ?

What about forms in PDF ?
(I don't know how to send back a filed pdf form)

SAM your advice is sound, however ...

Perhaps the OP could ask the user to buy a digital camera and take a shot
of the monitor screen, and then send that image over to the server?

The subject is: "How do I get HTML sent to server?".

Precisely. If the OP wants to see the closest anyone has come to
rendering dynamic HTML, look at Full Source (IE only)
http://www.thundermain.com/FullSource.html. Still, if you want the
web page generated by Full Source to look as it does it IE, you have
to blast the styles onto the page manually.

I can't believe I read this whole thread only to get to screenshots.
Maybe the OP could swing a deal with a disposable digital camera
manufacturer. The thread reminds me to be grateful that I work for a
company who's business model is based in reality.

Bob

[Captain Paralytic]

On 16 Jun, 18:03, "david.karr" <[e-mail]:

You might consider encapsulating the "legal" information into PDF and
archiving that. *That would be a more reliable rendering of what "they
saw", because PDF rendering is less variable between browsers.

I think more to the point is that PDFs are not rendered by browsers,
they are viewed through PDF viewers (e.g. Adobe Acrobat Reader)

[MC]

If your looking for the answer,
I was able to duplicate the page the user views. I sent the innerHTML back
to the server and it duplicated several test pages PERFECTLY with form data.

This is great as we can snapshot what the user sees when they print. It may
not be perfect but its good enough. Consistent, is the legal requirement,
not perfection.

function printForm() {
sendArchivalCopy(document.documentElement.innerHTM L);
window.print();
}

MC
PS using screenshots was never really considered.

[Lasse Reichstein Nielsen]

"MC" <mica[removethis]@aisus.comwrites:

If your looking for the answer,
I was able to duplicate the page the user views. I sent the innerHTML back
to the server and it duplicated several test pages PERFECTLY with form data.

The problem is that innerHTML is non-standard and doesn't work the same in
all browsers. In mine (Opera) it doesn't show the current value, but the
original value, of form controls.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[SAM]

MC a écrit :

If your looking for the answer,
I was able to duplicate the page the user views. I sent the innerHTML back
to the server and it duplicated several test pages PERFECTLY with form data.

This is great as we can snapshot what the user sees when they print.

When I print
I see nothing more at screen that is already displayed on the screen,
except the printer's dialog box.

It may
not be perfect but its good enough. Consistent, is the legal requirement,
not perfection.

function printForm() {
sendArchivalCopy(document.documentElement.innerHTM L);

it is what we say since ... houlala 30 posts ?

innerHTML doesn't work with tags input (and some others attributes)

Did you go to see my little demo about that ?

Once again, you can reasonably only get what is usual :
names of tags input and their values
sent by the form (or by JS function XMLHttpRequest if supported)

window.print();

That doesn't work with my IE Mac

}

MC
PS using screenshots was never really considered.

:-)

Dommage, j'aimais bien l'idée.

Usually,
- the filed form is send to the server (submitted by user),
- the server send back an unmodifiable copy
(without fields, only the values)
- the user push a button to agree (a new submit)
- the server save the same copy
and send back a message : all was correct (or not ...)
et merci et à bientôt

--
sm

[MC]

Sam,

We support IE and Firefox only. Since this is a business environment and not
consumer, we can dictate that. We also recommend IE7 as preferred since we
have several USB tools that have plugins to IE. We do try to validate W3C as
much as possible.

So Opera, Safari, etc are just not issues...out of over 2000 business users
we have there is not one Mac. The fact that the code is non-standard is a
non-issue.

MC
PS for the code to work, you need to finish out the sendArchive function
with ajax.

[SAM]

MC a écrit :

Sam,

We support IE and Firefox only. Since this is a business environment and not
consumer, we can dictate that. We also recommend IE7 as preferred since we
have several USB tools that have plugins to IE. We do try to validate W3C as
much as possible.

try my demo with Firefox (Fx does as Opera or Safari)
and try it too with IE (any of them 5)

MC
PS for the code to work, you need to finish out the sendArchive function
with ajax.

I will finish anything.

Functions type Ajax are on the Net :
<http://developer.mozilla.org/en/docs/AJAX:Getting_Started>
<http://jibbering.com/2002/4/httprequest.html>
<http://www.ajaxtoolbox.com/>
<http://ajaxpatterns.org/Ajax_Examples>

etc

--
sm

[Evertjan.]

MC wrote on 17 jun 2008 in comp.lang.javascript:

Sam,

[please always quote on usenet, this is not email, MC]

We support IE and Firefox only. Since this is a business environment
and not consumer, we can dictate that. We also recommend IE7 as
preferred since we have several USB tools that have plugins to IE. We
do try to validate W3C as much as possible.

So Opera, Safari, etc are just not issues...out of over 2000 business
users we have there is not one Mac. The fact that the code is
non-standard is a non-issue.

And the judge will just believe your dictate?

When you tell him you are showing a serverside reconstruction of what you
believe to have been on the users monitor, because you dictated something
to the defending party, and that that amounts to legal proof, he will have
a fit laughing.

Especially if the defence gets hold of this NG thread.

MC
PS for the code to work, you need to finish out the sendArchive
function with ajax.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[MC]

I thought this was a thread about getting client html sent back to the
server. I don't give a rats fat behind about your legal opinion as it
doesn't hold water here. Fact is, 'reasonable' and 'consistent' are key
ideals of the law here....not perfection. Guess we are just not as good as
you.

MC

[Evertjan.]

MC wrote on 17 jun 2008 in comp.lang.javascript:

I thought this was a thread about getting client html sent back to the
server. I don't give a rats fat behind about your legal opinion as it
doesn't hold water here. Fact is, 'reasonable' and 'consistent' are
key ideals of the law here....not perfection. Guess we are just not as
good as you.

To whom and to what are you responding?

You seem to have a lot to learn about usenet posting.

You seem angry, why? And at whom?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[MC]

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn*******************@194.109.133.242...

MC wrote on 17 jun 2008 in comp.lang.javascript:

>I thought this was a thread about getting client html sent back to the
server. I don't give a rats fat behind about your legal opinion as it
doesn't hold water here. Fact is, 'reasonable' and 'consistent' are
key ideals of the law here....not perfection. Guess we are just not as
good as you.

To whom and to what are you responding?

You seem to have a lot to learn about usenet posting.

You seem angry, why? And at whom?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

At whom???
I'm not angry. Frustrated maybe. Instead of helping, you are concerned about
criticizing my business. I didn't ask for business help, I asked for a how
to with javascript. Instead of help, I got a ranting about legal issues,
browsers, why something shouldn't be done, and rudeness. It seems that you
think its ok to usenet post garbage like this. I hope to not learn any of
your behaviors about usenet posting. It seems that you are trolling more
than helping and having fun doing it. I don't know why, as I know from other
posts that you are knowledgeable about javascript.

MC

[Evertjan.]

MC wrote on 18 jun 2008 in comp.lang.javascript:

>
"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn*******************@194.109.133.242...

>MC wrote on 17 jun 2008 in comp.lang.javascript:

>>I thought this was a thread about getting client html sent back to
the server. I don't give a rats fat behind about your legal opinion
as it doesn't hold water here. Fact is, 'reasonable' and
'consistent' are key ideals of the law here....not perfection. Guess
we are just not as good as you.

To whom and to what are you responding?

You seem to have a lot to learn about usenet posting.

You seem angry, why? And at whom?

[please do not quote signatures on usenet]

At whom???
I'm not angry. Frustrated maybe. Instead of helping, you are concerned
about criticizing my business.

I am not critisizing your business, I don't even know you have one.

As for helping, I think I am helping, but this is not a helpdesk, you are
not entitled to help and only that., this is usenet.

I didn't ask for business help, I asked for a how to with javascript.

So? You got your answer: impossible.

Recapitulating:

Clientside browser Javascript cannot get the full html of a page, and
even if it would, it would be reconstructed from the DOM, and not show
the actual image representation, as that is also dependent on window
size, Browser settings, type end version, screen size, operating system,
and more.

Instead of help, I got a ranting about
legal issues, browsers, why something shouldn't be done, and rudeness.

Haha, you are angry. Be angry at yourself. You explained you needed it
for legal purposes.

It seems that you think its ok to usenet post garbage like this.

That it is garbage is not what I hink, and it is not for you to decide
what is ok on usenet, that's what Netiquette is for.

Do you really think usenet is a helpdesk?

I hope to not learn any of your behaviors about usenet posting.
It seems that you are trolling more than helping
and having fun doing it.

So what if so? you are the asking party and you do not want to hear an
answer that would really help you: that your quest is useless, because
sending the html back by javascript is impossible, that reconstructing
the html [that you cannot get back] to an image is not your requested
legal proof.

I don't know why, as I know from other posts that you are
knowledgeable about javascript.

So do not despair, lay down that frustration, just take up the many
advises I and others have posted here in this thread to make an
alternative approach.

.... and never, never think anymore this is a paid [or even unpaid]
helpdesk, were posting a Q gives you privileges on specifying what
answers you want or do not want. After all, this is usenet.

.... and yes, I have fun, fun in helping, but not to the expense of
leaving you the false idea that it is possible to do what you ask, when
it is not.

.... and your ideas about usenet are funny indeed.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)