Right now, the PDF template that a set of mappings uses and the mappings themselves are inextricably linked. This means that in more dynamic applications of the module (such as sites that use Webform component labels (via Webform Tokens) to fill in questions on a PDF and use the values to fill in answers) the same PDF template is uploaded over and over and only the mappings vary.
With this change, the {fillpdf_fields} table would gain an additional column referencing the template that the mapping uses and gain its own unique ID. The {fillpdf_forms} table would remain the same, but the code would be updated to show the listing of Fill PDF mappings from {fillpdf_fields} with appropriate joins to {fillpdf_forms}. Each ffid (working name for the unique ID of {fillpdf_fields}) would equate to one listing on the overview page. The ffid would also become the number referenced in Fill PDF links. For backwards compatibility, the database update code would initially assign the ffid for existing mappings to the same value as the {fillpdf_forms} fid.
There will also need to be a page for updating and deleting unneeded templates. Uploading new ones would happen on the overview page still. Updating the PDF on a mapping might have to change in nature; instead of updating, the user would upload and switch to a different template. Allowing direct updating if that mapping is the only one using the template may still be practical.
This also means that parsing would not necessarily happen at template upload anymore, but rather upon creation of a new set of mappings or upon switching the associated PDF (which would also trigger migrating the field mappings, as it currently does).
This is a somewhat minor improvement, but it will support other usability and structural improvements as things progress.
Comments
Comment #1
wizonesolutionsI think this is pretty important for the new version as well. This is a definite architectural improvement. It would also open the door for other modules to make use of templates uploaded to Fill PDF. Not that they necessarily would, but I like those possibilities, especially when it's not a huge abstraction, just separating different concerns.
Comment #1.0
wizonesolutionsUpdated issue summary.
Comment #2
liam morlandComment #3
panchoThis proposal and #3049595: Consider composite primary key for FillPdfFormFields are mutually exclusive. In fact, in the D8 version, FillPdfFormFields currently have their own unique ID.
From what I understood, I'm not sure making FillPdfFormFields even more independent from their parent forms is a good idea. More flexibility, but also more complexity, less defaults, more configuration.
However, if that allows for the outlined usecase, we could decouple the template files from the FillPdfForms, so FillPdfForms could be duplicated, using the very same template file, rather than a copy of it. That I would pretty much endorse.
If I missed something, please help me better understand the initial post.
Comment #4
panchoComment #5
wizonesolutionsLooking at this 7 years later (it's important to look at old feature suggestions in the light of changes since then), I don't even remember what it was for. But I am inclined to just say that it's a conceptual duplicate of #3041152: [6.0.x] Consider turning FillPdfForms into ConfigEntities.
The actual use case mentioned in the issue summary is already possible by using multiple Webform submissions. I probably hadn't fixed that yet at the time or forgotten about it.
Comment #6
wizonesolutionsComment #7
wizonesolutions