Automatic Form Submission - without using JavaScript

[Lalit Mehra]

Is There a way apart from using scripting e.g. javascript to submit a form automatically?

The Scenario here is simple.

1. A form is displayed to the user
2. Upon Submission he is redirected to another jsp page (say interim.jsp)
3. interim.jsp has a form which i want to submit automatically without any user intervention

So, Is there a way to do it without using javascript? I can't find any though

regards

[Rajkamal Pillai]

Your query is not clear.

The title says "Automatic Form Submission - without using JavaScript" but the description says "submit automatically without any user intervention".

If you do not want the FORM submission to be user initiated how bout using a JavaScript timer?
Now if you mean you do not want to use any client script then I cant think of any way for doing that (if at all its possible).

Cheers,
Raj.

[William Brogden]

3. interim.jsp has a form which i want to submit automatically without any user intervention

What does the user have to do on the page with this form? Anything? If the user has to input something how will you know when he/she is finished?

If the user does not have to input anything then you don't want a form at all and can keep everything on the server in a session.

Bill

[Anil Kumar Goud]

You can use javascript's"setTimeout" to call function where you can define function defination to send form data after specified time with out user interaction.

[Bear Bibeault]

I think William's question needs answering: why are you doing this in the first place?

[Lalit Mehra]

Hi William/Bill,

I'm developing an application that runs on mobile phones.
I have to send some data to the client (on another server) through POST.
As some of the low end phones do not have javascript functionality, i cannot use auto submit or something else like that using javascipt.
So for that reason i asked ... if there's a way out ???

regards

[William Brogden]

Now that you have finally mentioned all of the requirements...... I don't think there is any way to do this without some active agent on the client, ie JavaScript.

I also suspect that the ability to do this would constitute a huge security hole - read this Wikipedia article on cross-site scripting. and some of the related articles.

Much better to tell your users what you have prepared as a request and give them the control over whether it gets sent.

You could always have your server do the POST to this other service and receive the response.

Bill

[Bear Bibeault]

But why are you doing this in the first place?

[Lalit Mehra]

Because it is a requirement. Simple.

[Ulf Dittmer]

William's remark got straight to the point: instead of submitting, redirecting and submitting again, why can't the server simply handle everything as the result of the first form submission?

Or maybe I'm not understanding correctly where the two pages are displayed - would they both be displayed on the same device? I'm also unclear what "send some data to the client (on another server)" - a form always submits to a server, not to a client.

[Bear Bibeault]

Lalit Mehra wrote:Because it is a requirement. Simple.

That doesn't help us one bit. As Ulf, William and myself have pointed out, there are likely alternatives that make more sense. Just saying "it's a requirement" doesn't give us any more information about what all of this is actually trying to accomplish than befire.

What is actually trying to be accomplished?

[William Brogden]

Unless of course you are actually trying to create an exploit - say sending credit card information to an invisible site. In which case we are not interested in helping you.

Bill

[Lalit Mehra]

Dear Ulf,
By Client I wasn't referring to the server-client terminology but the business one "you see a CLIENT".

William,
Thanks for the reply .. much appreciated and no i'm not trying to burn a hole in someone's pocket.

Bear,
I can't explain why the requirement is such ... but it is like this only ...

thanks for the replies guys ... much appreciated

[Ulf Dittmer]

Well, if you don't fully understand the requirements, nor can explain to us what it actually is that should be accomplished, I'm afraid we can't help you further.

[Tim Holloway]

A lot of requirements are defined by idiots.

Or, to be a little kinder, by people who don't understand the constraints of the architecture, think they understand more than they actually do and follow up with an "All You Have To Do Is..."

HTTP is not a continuous-connection protocol like client/server is. It's a strict request/response protocol where each response corresponds to a request in a strict 1-to-1 ratio.

In order to get an update, therefore, the client must submit a request. I think you understand that, but I wanted to lay out the fundamental strictures formally.

In order for a client to submit a request without human interaction, there must be some sort of active logic in the client that submits the request. Commonly, this is going to be JavaScript, although for simple whole-page refreshes, another alternative is a timed-resubmit metadata tag on the page to be refreshed (providing that the client honors this tag).

For mobile devices, one of the other alternatives is to submit requests from a J2ME, Android, or even ( ) dot-Net application installed on the phone itself. And guess what lucky person gets to create these apps?

A fundamental problem is that there simply is no universal lowest-common-denominator undercover automated submit framework for mobile devices. Some phones are, bluntly, too stupid to support anything at all. Although that particular segment is probably nearly extinct by now.

A more realistic goal is to define your audience, find out what options you can choose for that particular audience, and develop for those options. Don't expect to be all things to all people. You'll either have to simply not support the fringe cases or provide an alternative such as a manual submit button.

[Lalit Mehra]

Thanks for the kind words Tim.
Ulf, I can't disclose everything on a public platform. Hope you can understand.