Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20086 > unrolled thread

.submit(....) problem

Back to article view | Back to comp.lang.javascript

Contents

  .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-05-31 14:21 -0600
    Re: .submit(....) problem "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-05-31 23:47 +0200
      Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-05-31 18:32 -0600
        Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-05-31 22:49 -0600
          Re: .submit(....) problem JJ <duh@nah.meh> - 2013-06-01 14:18 +0700
            Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 09:07 -0600
              Re: .submit(....) problem Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-01 21:11 +0000
                Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 16:50 -0600
                  Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 17:10 -0600
                    Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 17:27 -0600
                      Re: .submit(....) problem Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-02 01:49 +0000
              Re: .submit(....) problem JJ <duh@nah.meh> - 2013-06-02 09:12 +0700
                Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 22:47 -0600
        Re: .submit(....) problem "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-06-01 12:02 +0200
          Re: .submit(....) problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-01 08:45 -0600

#20086 — .submit(....) problem

Hi:

    I send my client a very bland, mostly empty page (with <form> ... 
</form> as part of the page).

    Via <select> elements and choices, the client (thru my 
ECMAscript/javascript ) changes the content of the display on the screen..

    Then, when the client submits the form:

            getobj("isubfrm").submit() ;

        ... the client's page display contents *revert* to the original page 
my server sent him/her!

    But, I wish the page display to stay at what if was finally set to *just 
prior to the .submit*  --- until the replacement page is received.

    Can some explain what I have to do to remedy this situation please ?

Thank you.

-- 
Mel Smith

[toc] | [next] | [standalone]

#20094

Mel Smith wrote on 31 mei 2013 in comp.lang.javascript:

>     I send my client a very bland, mostly empty page (with <form> ... 
> </form> as part of the page).
> 
>     Via <select> elements and choices, the client (thru my 
> ECMAscript/javascript ) changes the content of the display on the
> screen.. 
> 
>     Then, when the client submits the form:
> 
>             getobj("isubfrm").submit() ;
> 
>         ... the client's page display contents *revert* to the
>         original page 
> my server sent him/her!
> 
>     But, I wish the page display to stay at what if was finally set to
>     *just 
> prior to the .submit*  --- until the replacement page is received.
> 
>     Can some explain what I have to do to remedy this situation please
>     ? 
> 
> Thank you.

<form target='nameofhiddeniframe' ...

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

[toc] | [prev] | [next] | [standalone]

#20096

Evertjan said:

">
> <form target='nameofhiddeniframe' ...
>

Hi Evertjan:

    I'm using the Document type for HTML 5, and the 'target' property  is 
deprecated, *and*

    I don't know what you intend me to do with your 'nameofhiddeeniframe' 
anyway --- what iframe ??    :(

    Also, I just 'mod_deflated' my particular site, and *now* my page 
remains the same until the '<form>' is responded to with a new page. 
Surprise for me !

Its time for (another) beer ...

Thanks anyway,

-Mel

[toc] | [prev] | [next] | [standalone]

#20097

I said:
> Hi Evertjan:
>
>    I'm using the Document type for HTML 5, and the 'target' property  is 
> deprecated, *and*
>
>    I don't know what you intend me to do with your 'nameofhiddeeniframe' 
> anyway --- what iframe ??    :(
>
>    Also, I just 'mod_deflated' my particular site, and *now* my page 
> remains the same until the '<form>' is responded to with a new page. 
> Surprise for me !
>
> Its time for (another) beer ...


Hi Evertjan:

    Now I think I understand:

    My post contained the following:

            getobj("isubfrm").submit() ;

            (which may give hints of iframes  I guess ...)

    But the getobj() function is just a function that I use to shorten the 
statement  'document.getElementById("isubfrm") '   where the "isubfrm" is 
the ID of the <form> element.  i.e.

        function getobj(cID) {
            return document.getElementById(cID) ;
        }

    This save me a lot of typing time and reduces my chance of typos.

    ... and there are no iframes involved -- as far as I know ...

-Mel Smith

[toc] | [prev] | [next] | [standalone]

#20098

On Fri, 31 May 2013 22:49:42 -0600, Mel Smith wrote:
>     Now I think I understand:
> 
>     My post contained the following:
> 
>             getobj("isubfrm").submit() ;
> 
>             (which may give hints of iframes  I guess ...)
> 
>     But the getobj() function is just a function that I use to shorten the 
> statement  'document.getElementById("isubfrm") '   where the "isubfrm" is 
> the ID of the <form> element.  i.e.
> 
>         function getobj(cID) {
>             return document.getElementById(cID) ;
>         }
> 
>     This save me a lot of typing time and reduces my chance of typos.
> 
>     ... and there are no iframes involved -- as far as I know ...

What was suggested is to use IFRAME as the container for both the form, and
the result. So there need to be at least 3 different pages:

1. The main page that host the IFRAME.
2. The form page which is served in that IFRAME.
3. The result page after the form is submitted - still in the IFRAME.

If you don't want to use IFRAME, then you'll have to make the server return
only the form result instead of the whole page.

Once that's done, use AJAX to submit the form. You can find an example at
the bottom of this page (warning: long URL):

https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Sending_forms_through_JavaScript

In that sendData function, instead of showing a message alert, put the
received data into a DIV's innerHTML property, or use the form's DIV
container.

[toc] | [prev] | [next] | [standalone]

#20106

JJ said:

> What was suggested is to use IFRAME as the container for both the form, 
> and
> the result. So there need to be at least 3 different pages:
>
> 1. The main page that host the IFRAME.
> 2. The form page which is served in that IFRAME.
> 3. The result page after the form is submitted - still in the IFRAME.
>
> If you don't want to use IFRAME, then you'll have to make the server 
> return
> only the form result instead of the whole page.
>
> Once that's done, use AJAX to submit the form. You can find an example at
> the bottom of this page (warning: long URL):
>
> https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Sending_forms_through_JavaScript
>
> In that sendData function, instead of showing a message alert, put the
> received data into a DIV's innerHTML property, or use the form's DIV
> container

Hi JJ:

    I read over your post again, and printed the 14-page link, and will 
study it carefully. I have already used the AJAX procedures (lightly)  two 
years ago, but will shortly have need for them again -- so thanks again for 
the link.

    My original problem (very probably phrased crappily) was to leave the 
client's page 'frozen' at the point-in-time of submission of <form> info 
until the reception of the *new* page. This new page can take from < one 
second to sometimes up to ten seconds for my server app to do all the work 
of building the response page, and sending it. (the page can sometimes be up 
to 382K in size). So, while this work is being carried out, I wish the 
client's view of the original page be 'frozen' at what my JS code left it at 
just prior to the .submit sequence.

    Now, serendipitously,  by using gzip (i.e., mod_deflate) in my Apache 
Server, this *does now* happen.   So, my problem is (I guess) solved -- but 
I don't understand why
.
    Re: your suggestion of AJAX ---  I will be using it for the next stage 
to update info in the page..

Thank you.

-Mel

[toc] | [prev] | [next] | [standalone]

#20107

On Sat, 01 Jun 2013 09:07:17 -0600, Mel Smith wrote:

>     My original problem (very probably phrased crappily) was to leave
>     the
> client's page 'frozen' at the point-in-time of submission of <form> info
> until the reception of the *new* page.

This probably falls over because your server starts sending the new page 
before it has finished assembling it - as soon as the browser gets part 
of the new page, it clears out the old one and starts to display what 
it's received so far of the new one.

>     Now, serendipitously,  by using gzip (i.e., mod_deflate) in my
>     Apache
> Server, this *does now* happen.

That's probably because using compressed pages, your server doesn't start 
the compression until the whole page/file is prepared, so it doesn't send 
the page until it's been fully created.

The more complete solution in your server side script might be not to 
send any non-header content until you have finished preparing the page.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#20109

Denis said:
> This probably falls over because your server starts sending the new page
> before it has finished assembling it - as soon as the browser gets part
> of the new page, it clears out the old one and starts to display what
> it's received so far of the new one.

    Unfortunately No .    I build the whole page (sometimes up to 382K) 
inside my CGI app.  When it is completely assembled, I output it at once to 
my Apache 2.2.22 server. I will 'time' the building in my cgi app, and see 
how long it taks to receive, assemble, and send -- I'll let you know

>
>>     Now, serendipitously,  by using gzip (i.e., mod_deflate) in my
>>     Apache
>> Server, this *does now* happen.
>
> That's probably because using compressed pages, your server doesn't start
> the compression until the whole page/file is prepared, so it doesn't send
> the page until it's been fully created.
>
> The more complete solution in your server side script might be not to
> send any non-header content until you have finished preparing the page.


    As noted above, I follow the same procedure in my CGI server app, and 
when the page is built and complete, I output it to Apache where it is 
(assumedly) 'gzipped' and then is sent off to the client.

    So, I'm still perplexed.

    But, what I see on my client's screen (which is really *me* testing) is 
my final content I wish left in place, but displayed only for a 
split-second, then the screen reverting to the original screen, then a long 
wait, then the new screen displays.

    So, it is between the 'submit' and the reception that something happens 
to revert to the original screen during the wait process..

    I'll have to take this to bed with me again and hope I get an 
inspiration.

Thanks for the comment.

-Mel

[toc] | [prev] | [next] | [standalone]

#20111

I said:

>    Unfortunately No .    I build the whole page (sometimes up to 382K) 
> inside my CGI app.  When it is completely assembled, I output it at once 
> to my Apache 2.2.22 server. I will 'time' the building in my cgi app, and 
> see how long it taks to receive, assemble, and send -- I'll let you know
>

Hi Denis:

    I just put a timer in my cgi app.  For my largest file (approx 382K), it 
takes only 0.33 seconds from the time I receive the original <form> elements 
(i.e., the POST) until I output and pass the rebuilt and re-assembled page 
(382K) to Apache for compression.

    Then, does that mean that the 'reception' and 'unravelling' of this new 
big page back at the client causes it to *first* revert to the original page 
before displaying  the new (much bigger) page ???

Thanks for commenting.

-Mel
 

[toc] | [prev] | [next] | [standalone]

#20112

I said (again):

> Hi Denis:
>
>    I just put a timer in my cgi app.  For my largest file (approx 382K), 
> it takes only 0.33 seconds from the time I receive the original <form> 
> elements (i.e., the POST) until I output and pass the rebuilt and 
> re-assembled page (382K) to Apache for compression.
>
>    Then, does that mean that the 'reception' and 'unravelling' of this new 
> big page back at the client causes it to *first* revert to the original 
> page before displaying  the new (much bigger) page ???


Hi Denis:

    Put another 'alert()' in my page (just after the <body> tag) , and 
determined that the new big page arrives back at the client very quickly 
(<0.5 secs), and then the fixed/frozen page is reverted to the *original* 
page while the new bigger page is being unravelled/digested --- approx seven 
seconds to do this 'onload' stuff !

Wow !

-Mel
 

[toc] | [prev] | [next] | [standalone]

#20115

On Sat, 01 Jun 2013 17:27:00 -0600, Mel Smith wrote:

>     Put another 'alert()' in my page (just after the <body> tag) , and
> determined that the new big page arrives back at the client very quickly
> (<0.5 secs), and then the fixed/frozen page is reverted to the
> *original* page while the new bigger page is being unravelled/digested
> --- approx seven seconds to do this 'onload' stuff !

Have you tried different browsers?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#20116

On Sat, 1 Jun 2013 09:07:17 -0600, Mel Smith wrote:
>     My original problem (very probably phrased crappily) was to leave the 
> client's page 'frozen' at the point-in-time of submission of <form> info 
> until the reception of the *new* page. This new page can take from < one 
> second to sometimes up to ten seconds for my server app to do all the work 
> of building the response page, and sending it. (the page can sometimes be up 
> to 382K in size). So, while this work is being carried out, I wish the 
> client's view of the original page be 'frozen' at what my JS code left it at 
> just prior to the .submit sequence.

The common method is to add an absolute/fixed positioned DIV that cover the
entire page view (at the topmost z-index). The DIV must have a background
color or image, and be make translucent using the opacity style (e.g.:
opacity=0.5).

Just show it before submitting the form, then hide it after the result has
been received. So you'll need to have either onload or onreadystatechange
handler, depending on which method you're using (IFRAME and/or AJAX), in
order to be notified when the result has been completely received. Hint:
check the readyState property.

[toc] | [prev] | [next] | [standalone]

#20117

Denis & JJ:

    Can't work on this until Monday.  Going golfing for the day with my 
sons.

    Thanks for your suggestions !

    Will review them over the next two days.

To Denis:

    I test on my XP dev machine with IE8, then with IE9 on a Win 7 Home 
Premium laptop, then also check regularly on Chrome and FF on my XP machine

    Chrome , IE9, and FF are noticeably faster than IE8 but the results are 
similar across all browsers.

So, I guess I have to look at all I'm doing in the 'onload=' stuff within 
the big page, and see if I can somehow show the big page quicker, and then 
try to do some of the big JS crunching behind the scenes while the client is 
getting ready to start clicking buttons, or searching, or whatever ...

Thanks again.

-Mel

[toc] | [prev] | [next] | [standalone]

#20101

Mel Smith wrote on 01 jun 2013 in comp.lang.javascript:

> Evertjan said:
> 
> ">
>> <form target='nameofhiddeniframe' ...
>>
> 
> Hi Evertjan:
> 
>     I'm using the Document type for HTML 5, and the 'target' property 
>     is deprecated, *and*

deprecated, but you can use it for many years to come.

> 
>     I don't know what you intend me to do with your
>     'nameofhiddeeniframe' 
> anyway --- what iframe ??    :(

<iframe style='display:none;' name='nameofhiddeniframe'>...

>     Also, I just 'mod_deflated' my particular site, and *now* my page 
> remains the same until the '<form>' is responded to with a new page. 
> Surprise for me !

Don't know what you are talking about.

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

<form result can be sent to another page, be it a new one or a previously 
made one, or to a frame or to an iframe. The nice thing about the iframe 
is that you can hide it [a frame too, but that is less elegant, imhv]


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

[toc] | [prev] | [next] | [standalone]

#20105

Hi JJ & Evertjan:

    I'll puzzle over both your responses.

Thank you.

-Mel

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web