If you need to access a DB then you have to create your form in LiveCycle Designer.
Acrobat PDF forms can no longer do that.
This just means that data will be exported in the form of an HTML page. I don't really know anyone that uses that option, and don't see how it relates to what you talking about.
Right so if I break it down:
1. The user opens the PDF Form in Reader and starts to fill it out
2. They get to the part of the form where they enter a ID number and hit a submit button
3. The form remains open, while the submit button sends the ID number via html to localhost:xxx
4. A helper application also running on localhost listens for the ID number in the html - when it receives it, it runs a query on a database to get a result set containing name, address etc.
5. This data is then somehow (HTML? XFDF?) returned to the PDF form which is still open?
I am not very clear on step 5 yet - but 1-4 definitely seem possible?
Hope this makes the question clearer?
This just means that data will be exported in the form of an HTML page.
Almost correct The data will be posted to a web server as an HTML post request. This means that if you know how to write software that can accept data from a web form, you can also use that to process your PDF form data. This is actually the default format that I use unless I have a very good reason to use either FDF or XFDF.
The only way you get communicate with a server while filling out a form is via the Net.HTTP/SOAP interface, which means that you will need "Forms" rights in your documents for Reader to be able to process these commands. These extended rights cannot be assigned with Adobe Acrobat, you will need the LiveCycle Reader Extensions server solution for that. And, you also need to install a folder level script on every computer that will process these documents, because the Net.HTTP.request function cannot be used from within the document context.
Thanks for the correction.
After thinking about this for a bit more, what you could do is keep track of the state of you form: When you fill out the first half of it, you start out in state one. When you need the ID number, you submit the form as FDF data (or XFDF). Your server process then analyzes the data and generates an ID number and creates a new FDF/XFDF data structure that contains the original data, the ID number and a pointer to a blank copy of the document. When this is now downloaded to the client, it will automatically open the linked PDF file and populate the data with the data from the FDF/XFDF file. You are now in state 2, and the user fills out the remainder of the form. When the form is finalized, and submitted, your server process knows that it's no longer required to generate the ID number, but can now save the data/forward it via email/ ...
BTW: Forget about this working in Chrome. You will need Adobe Reader for this to work.
That's more complicated than it needs to be. It seems there is a local program that acts as a web server the the form can be submitted to. Submitting as "HTML" is fine and probably the easiest to parse, but data for any number of fields can be returned in an FDF, so there's no need to load a new form. This has been possible since forms were introduced with Acrobat/Reader 3 and similar to what AJAX provides for HTML forms.
We have java installed on all our devices for other things - they lets us run our own java programs, but access to \Program Files\ is locked. Strange but true. So I can write a java app to parse the data.
I am curious about your solution - when you say return the result set via FDF - can you explain in a little more detail?
I have taken the existing form and exported the data as FDF so I know the format of the file, but how is this file returned to update in realtime a open form?
Thanks for everyones input so far.
Before I say anything more, have you confirmed that you're able to submit locally and access the data that's submitted? It needs to behave like a web server (HTTP/HTTPS).
Well I have not written the code, but I have watched in wireshark while I hit the submit button and can see the requests to send the TCP packets....
I think submitting to a Java app that's acting like a local web server is probably the last approach you should take. Probably the simplest is the XFA form approach, assuming you can set up each client with access to the database.
The web server approach can work, but it involves a lot more work and it's not clear to me why it has to be a local web server. Is the database local to each workstation as well?
The database is a centralized database with a propriety interface on each PC. Suffice to say there is no way that the central database can be accessed from a PDF, hence the reason for a java based "helper" to act as a go between.
I agree it is less than ideal! but I dont see anyway around it?
yyou can return an fdf with specified field names. These fields are set in the PDF, and could be hidden. Not sure submitform is synchronous.
George said: "That's more complicated than it needs to be"
Yup, you are right, I was passing a brain stone and not thinking straight
The mechanism that George described is possible and will work, the trick is to get everything working together correctly. You are dealing with a client side and a server side if you want to do this. One of the problem you will run into is how to get access to the FDF or XFDF data when you submit the form data to your server process. It's not done in the obvious way (as a file attachment), the data will be submitted as raw data during the HTTP POST request. Because we don't know how exactly you are going to implement your Java server, I cannot provide any more information about how to do that in Java, but I can tell you that in a Python server based on SimpleHTTPServer, I am using self.rfile, and in PHP I get the data via php://input
I would recommend that for experimenting, you are not working on your own server process, but use a an existing server so that you can concentrate on debugging your problems with the two parts communicating, and not the low level sever stuff. So, either setup you own server and run e.g. a PHP script on the server to receive and send the FDF/XFDF data, or whip up a quick Python web server based on the SimpleHTTPServer in which you define your own do_POST method.