How does "Submit to HTTP" work?

[#1]

I would like a form to submit its data for a URL. I have created a "Submit to HTTP" button, in LiveCycle Designer 8. What's the URL supposed to look like? If I create a URL with no file, I get a "File Not Found" error, when I attempt to submit form data. When I create an empty text file, I get a "General Error" message.



I have a PDF form to send to many recipients. I would like the results for each respondent to be written to a new row, in a file located at my URL.



This is incredibly easy to do, with a webform, but seems impossible, with LiveCycle Designer 8.



What is form data being written to, at that URL?



Is there any information about "Submit to HTTP" - a tutorial for the whole darned thing - that I can read somewhere? I've not been able to find much of anything (lots about submitting data via email, which I don't want to do) on this topic, on Adobe's site.

[_Aandi_Inston_]

I think you have made the common mistake of thinking that "submit"

means "save". You can't just write a file to a web server: web servers

are read-only. Imagine the security issues otherwise, if anyone could

stick things on your site.



When you submit a form, you give the URL of web program (also called a

script, sometimes a CGI, an ASP, or a PHP: just different kinds of

program).



This program, written by a web programmer, reads the information that

is submitted, and does something with it. What it does is up to the

ideas and skills of the programmer. It could

* put information in a database

* send an e-mail

* load files to the web site directly (beware, there are important

security issues).



There are tutorials, and entire books and course, on web programming,

but it's a big subject, and needs great care if you aren't going to

leave your web site wide open to hackers.



Essentially this is much the same thing that happens whenever you fill

a form or click a button on any web site, including this one (though

the programs are rather more complicated).



You are absolutely right not to use e-mail.



Aandi Inston

[#3]

Just curious ...



What is the matter with using submit via email? The form I am working on now would be hosted on a password protected portion of our non-profit organization's web site. This area would be accessible ONLY to our board members & staff. This particular form is a request for reimbursement that needs to be sent (preferably via email as a PDF) to our secretary & treasurer. As a PDF, then they can print them out so that we have a hard copy(as well as a digital copy) for our records.



Would submitting via email cause any problems in a scenario like this??



~kma

[_Aandi_Inston_]

>What is the matter with using submit via email?



So many, many, things.



Leaving aside the possibility of e-mails getting lost in transit, or

blocked by spam filters, a key problem is that it requires the user to

have set up their default e-mail client.



Many people have more than one e-mail client installed, but only use

one; things sent to the wrong one may just sit in an outbox forever.



Many people have no working e-mail client at all; millions use

hotmail, yahoo, or similar.



> This particular form is a request for reimbursement that needs to be sent (preferably via email as a PDF) to our secretary & treasurer.



This runs into another problem. Reader can't submit or e-mail in PDF

format, unless you enable this in Acrobat Professional 8. But you MUST

limit this to no more than 500 uses of the form, or you are in breach

of the license.



>As a PDF, then they can print them out so that we have a hard copy(as well as a digital copy) for our records.



This is probably missing the point of the form data submissions, which

can readily be reimported to the PDF.

>

>Would submitting via email cause any problems in a scenario like this??



What proportion of lost claims is acceptable?



Aandi Inston

[#5]

CAN you pls construe little on that:

<no working e-mail client>

[_Aandi_Inston_]

>CAN you pls construe little on that:<br />><no working e-mail client><br /><br />If you don't need an e-mail program, you probably won't have one set<br />up to work.<br /><br />Millions of people use hotmail, yahoo or whatever for their e-mail. So<br />there is no program on the computer for Acrobat or Adobe Reader to<br />send e-mail with.<br /><br />E-mail cannot be magically sent by Acrobat, it relies on other<br />programs being correctly set up.<br /><br />So, I repeat: e-mail "submission" is really not for serious or<br />commercial use.<br /><br /><br />Aandi Inston

[Robert_Hirst]

Aandi is saying that not everybody uses a desktop email client for email, many people now only have web mail accounts.



In that scenario, when they click submit via email, even if the message with the data/pdf does pop up in a their system's default mail client (Outlook Express etc.) it will not be configured (no account set up), so they will be unable to submit the form and will probably give up, frustrated.

[Jared_Langdon]

Submitting by HTTP works well if your PDF is in a browser, but that's not always the case. Even if you present the PDF in a browser in the first place, it's hard to prevent a user from saving it offline. If a user tries to do an HTTP submit outside the browser you usually get unintented results. If the user has Acrobat, your response may get converted to PDF, which is almost certainly not what you want. If the user has Reader, they may get an error message saying that Reader could not display the (HTML) response. So, as much as e-mail submit has its problems, I've found that HTTP submit has some too. I'm interested in what others have done about this problem. What's the best practice? Here are some ideas:



1) Use a web service instead of HTTP submit (only works in Acrobat or with usage rights applied)

2) Do an HTTP post using the FormCalc Post function and handle the result in JavaScript in the form. I recently learned about this one on this forum, but I haven't used it. It sounds promising. Are there any gotchas?

3) Use a JavaScript to check if Acrobat/Reader is in a browser or stand-alone and do an HTTP submit or e-mail submit respectively.



Others?

[Robert_Hirst]

"If the user has Reader, they may get an error message saying that Reader could not display the (HTML) response."



I've just checked and initial test indicates that if you respond with a PDF from the URL you specify for submission then Reader will open a new window with this PDF file in.



Has anyone tried this approach and if so have you encountered any issues with it?



It so far seems to be the only way to meet my current requirements:



1. Data is personal and must be submitted securely over SSL (so no email)

2. Data must trigger a LiveCycle Process, but users do not and can not have logins for the server (so no Workbench, although the people processing the forms will be using this).



If anyone has any other strategies then I'd love to hear them.

[NotSmug]

So, I'm having a similar problem as the other "authors," but now I think I'm just going to change products.  Aandi's smug responses are all over these boards.  You know, if you don't want to answer Aandi, then don't answer.  But belittling peoples' choice to submit forms via Email is rediculous.  Let me prove it:

1.  I have 4 forms that allow people to request more information, and I want them in the original format so I can save the pdf in SalesForce.  You know, a non-Adobe product.  Shocking.

2.  I don't want to pay a web designer un-Godly dollars to write scripts directing forms to a database, then back to me.  It makes more sense to just email me the form.

3.  I might want to print it when I get it.  Can I do that with a web form?  Absolutely.  Except, again, I have to pay someone to feed it to a database, then to a reporting system to reformat the data in *gasp* basically the way it was in Adobe to begin with.

4.  Acceptable loss statements about Email is pretty stupid these days.  I could have similar or greater loss with a "hiccup" in a web server that makes someone 404 out and have to come back and re-enter the information from scratch.  Which, by the way, most never do if its not something of the utmost importance.

5.  If "Submit by Email" wasn't useful or called for, why would you brain surgeons put it in the product?  "For testing purposes" doesn't seem honest.  What does seem honest is that some massive clients of Adobe's wanted it, and I bet you weren't smug to them.  You built it in.  Period.

What a jerk.