P
Peter Horlock
Hi!
Our company has a lot of different pdf forms,
currently about 50. Each has about 20 different
text- checkbox and or radio button fields.
These ~1000 different fields should be filled with
about 70-100 different values, mostly coming from our database,
often there is some business logic to “create†the data that will be
filled into the form, but for the text fields, the values are very often
just the same ones. However, the field names are almost never the same ones,
even in the same pdf, even on the same page – they are created by
different business units and or other clients, so we cannot change them.
Therefore, I thought about a mapping mechanism
that would map the about 100 different values to the 1000 different fields.
For the text fields, this would be relatively easy – I would define a
mapping sceme, for example a simple xml file for each pdf that would map
the field names to unique java functions in my code.
So e.g. the mapping
<mapping key=â€Country 1239†value=â€setCountryCodeâ€/> would dynamically
set the country code into the pdf before beeing downloaded.
However, I can’t find a good solution for radio buttons and checkboxes.
These fields have a value in the pdf that will trigger them to be
selected. But the meaning –
e.g. “1†means “male†or “female†can only be seen graphically if you
print out the pdf.
It get’s even more complicated for checkboxes, where each value might
set something completely different.
E.g. “My favorite color is “greenâ€, “blackâ€, “whiteâ€, “blueâ€â€¦â€¦â€
With trigger values of “abc†for green and “1†for black and “9†for
white and “BBB†for blue - this is all defined in the pdf form and we –
the IT – do not have any influence on those settings and their meanings.
Therefore, I thought of a solution to only map the text fields and to
still manually code the business logic for radio- and check boxes.
+ That way, we would have one class each for each form, but each class
would only consist of the business logic for the checkboxes and radio
buttons.
- However, the down side of this is that then you have to different ways
of how the forms get filled - an automated part and a manual part.
The xml mappings could be completely managed by our internal clients,
while all other fields would still need to be hand coded.
Another option would be to also define a mapping for radio- and check
boxes, where you would only fill out the name of the box, and then in
the code you would write the business logic. If the parser would then
find a radio button or check box, it would read the name of the field
and would hand over the execution to a specific fitting method.
+ So we would have all logic together in one central class for all pdfs,
- but this class would grow bigger and bigger......
Okay, we could then put all radio box methods into a single class and
all check box methods into another, but still, these two classes would
grow and grow with each new form.
In other words, I don't like either of these 2 solutions.
Maybe you got a better idea??
Thanks in advance,
Peter
Our company has a lot of different pdf forms,
currently about 50. Each has about 20 different
text- checkbox and or radio button fields.
These ~1000 different fields should be filled with
about 70-100 different values, mostly coming from our database,
often there is some business logic to “create†the data that will be
filled into the form, but for the text fields, the values are very often
just the same ones. However, the field names are almost never the same ones,
even in the same pdf, even on the same page – they are created by
different business units and or other clients, so we cannot change them.
Therefore, I thought about a mapping mechanism
that would map the about 100 different values to the 1000 different fields.
For the text fields, this would be relatively easy – I would define a
mapping sceme, for example a simple xml file for each pdf that would map
the field names to unique java functions in my code.
So e.g. the mapping
<mapping key=â€Country 1239†value=â€setCountryCodeâ€/> would dynamically
set the country code into the pdf before beeing downloaded.
However, I can’t find a good solution for radio buttons and checkboxes.
These fields have a value in the pdf that will trigger them to be
selected. But the meaning –
e.g. “1†means “male†or “female†can only be seen graphically if you
print out the pdf.
It get’s even more complicated for checkboxes, where each value might
set something completely different.
E.g. “My favorite color is “greenâ€, “blackâ€, “whiteâ€, “blueâ€â€¦â€¦â€
With trigger values of “abc†for green and “1†for black and “9†for
white and “BBB†for blue - this is all defined in the pdf form and we –
the IT – do not have any influence on those settings and their meanings.
Therefore, I thought of a solution to only map the text fields and to
still manually code the business logic for radio- and check boxes.
+ That way, we would have one class each for each form, but each class
would only consist of the business logic for the checkboxes and radio
buttons.
- However, the down side of this is that then you have to different ways
of how the forms get filled - an automated part and a manual part.
The xml mappings could be completely managed by our internal clients,
while all other fields would still need to be hand coded.
Another option would be to also define a mapping for radio- and check
boxes, where you would only fill out the name of the box, and then in
the code you would write the business logic. If the parser would then
find a radio button or check box, it would read the name of the field
and would hand over the execution to a specific fitting method.
+ So we would have all logic together in one central class for all pdfs,
- but this class would grow bigger and bigger......
Okay, we could then put all radio box methods into a single class and
all check box methods into another, but still, these two classes would
grow and grow with each new form.
In other words, I don't like either of these 2 solutions.
Maybe you got a better idea??
Thanks in advance,
Peter