I have this workflow.
My assumption: you have an interactive PDF document with AcroForm fields similar to submit_me.pdf:
The main difference, is that I have different buttons on the form:
The SubmitForm example shows how the buttons were added to an existing form. Note that there are more options than the ones described in this example.
For instance:
To show you what to expect when you commit a form, I wrote the ShowData servlet. This servlet returns the bytes that are sent to the server.
In case of a POST:
personal.loginname=jdoe&personal.name=John+Doe&personal.password=test&personal.reason=reason&post.x=29&post.y=7
Note that I also defined the button in such a way that the coordinate of my click is passed to the server. You probably don't need this.
In case of FDF:
%FDF-1.2
%âãÏÓ
1 0 obj
<</FDF<</Fields[<</T(FDF)>><</Kids[<</T(loginname)/V(jdoe)>><</T(name)/V(John Doe)>><</T(password)/V(test)>><</T(reason)/V(Reason)>>]/T(personal)>>]/ID[<EF0089E16ED50F11CB6057A700B9046E><1205D069D1D6AE37665B6FF7EEA65414>]>>/Type/Catalog>>
endobj
trailer
<</Root 1 0 R>>
%%EOF
In case of XFDF:
<?xml version="1.0" encoding="UTF-8"?>
<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve"
><f href="http://itextpdf.com:8180/book/submit_me.pdf"
/><fields
><field name="XFDF"
/><field name="personal"
><field name="loginname"
><value
>jdoe</value
></field
><field name="name"
><value
>John Doe</value
></field
><field name="password"
><value
>test</value
></field
><field name="reason"
><value
>Reason</value
></field
></field
></fields
><ids original="EF0089E16ED50F11CB6057A700B9046E" modified="1205D069D1D6AE37665B6FF7EEA65414"
/></xfdf
>
In an ideal world, this would be your solution. It is described in ISO-32000-1 which is the world-wide standard for PDF. However: many people started using crappy PDF viewers that do not support this functionality, so if you want to use this solution, you'll have to make sure that people use a decent PDF viewer as their browser plug-in.