Last time we looked at building and pre-filling the PDF data entry form. We now need to look at how we can allow the user to 'submit' the data they have entered back to the server and to then let them know that their data has been received.
There are a several of ways that Adobe will allow you to post data from a form. 
Im using Adobe 6 you may be on another version, things should be similar thou. The properties dialog, for a button reveals the folloiwn submission methods:
- FDF - this is Adobe's 'Form Data Format' - you can get more info on this here. It's a proprietory format for sending (and receiving) form data and comments. Im not going to deal with this format.
- HTML - need I say more except Im not going to deal with this either
- XFDF - XML Forms Data Format. Yep, you guessed it, it's Adobe's proprietory XML format for the forms data - now this we can and will use. Not the friendliest format but guess what? We have an API for that.
- PDF - you can just submit the complete PDF form. This is useful if you wanted to store a copy of a form created by a user. Even better if they signed the form with a digital signature - as good as a paper signature. Of course we need to scrape the data out of the form too - yep, we have an API for that too and we're going to try that too.
Now I guess you could use the HTML format and Adobe provides an SDK to parse the FDF format but why bother, Publisher has all you need for for the last two formats and they have enough information.
Using the properties dialog we can choose XFDF or PDF. Initially I chose XFDF, I need to POST the XFDF to some CGI process on a web server. I elected to use a servlet. Looking at the graphic above you'll see I have entered a URL. Therein lies an issue, I have hardcoded the URL on the button - you got it. We have an API for that, now I have to admit this one is hidden and again I lent on Incheol for information.
We have an undocumented class FieldEditor, as the name suggests you can edit fields with it - that includes adding fields too. So, we can create the button in its entirity and enter the submission destination and format and then put it on the page.
We first need to instantiate a PDFParser object, this takes the file we want to edit as an input. We then create a FieldEditor object and add the button and then re-generate the form. The addButton method takes a series of parameters.
addButton(btnName(String),
btnLabel(String),
btnfontSize(float),
btnCode(String),
btnCoords(float[],
btnPage(int),
btnType(int))
Most I hope are self explanatory except maybe:
btnCode - you can create a submit or javascript type button and here is where you pass either the
//Add the button
float[] btnCoords = {350f,350f,470f,380f};
float fontSize = 16f;
String btnName = "SUBMIT_BTN";
String btnLabel = "Submit";
String btnDest = "http://www.oracle.com";
int btnPg = 0;
//Create a PDF Parser instance
PDFParser pdfP = new PDFParser(pdfForm);
//Create a FieldEditor instance
FieldEditor fldEd = new FieldEditor(pdfP);
//Add the button
fldEd.addButton(btnName,btnLabel,fontSize,btnDest,btnCoords
,btnPg,fldEd.BUTTON_ACTIONTYPE_SUBMIT_FORM);
//Regenrate the form
fldEd.generatePDF(pdfForm);
Now the only drawback is that the API does not let you influence the look and feel of the button, so you get a flat button ... not exactly a nice beveled 'clickable' affair but it gets the job done. Before you ask, no there is not a method to update a button. We can look into that if enough of you scream loud enough. I also have to admit that we do not give you the control over the posting format of the button e.g. XFDF, PDF, etc. It defaults to HTML ... dang - Im logging an enhancement for this today.
Apologies for this tangent we got on to with buttons that led down a rather disappointing cul-de-sac. Next time, we get into receiving the contents of PDF via a servlet and letting the user know we got their information.
