Postponed
Project:
FillPDF
Version:
8.x-4.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
6 Apr 2012 at 11:02 UTC
Updated:
5 Apr 2019 at 08:24 UTC
Jump to comment: Most recent
When using contributed modules like LoginToboggan that intercept Access Denied pages and then redirect to the attempted page after a login, the Fill PDF Link format doesn't work. This is because these modules tend to strip off the query string parameters. Fill PDF uses query string parameters for maximum flexibility, but this is probably not the best way to do it.
So I want to think about if Fill PDF could start transitioning to a more Drupal-standard URL format, e.g. /fillpdf/<fid>/<nids>/<sids>.
This could work because the explicit distinction between nodes and webforms is actually unnecessary; we can tell from the node type whether it's a webform or not. Multiple nids could be separated by hyphens or commas (hyphens look a bit neater). So we could have something like:
http://example.com/fillpdf/1/2 (node) or:
http://example.com/fillpdf/1/2/3 (webform) or:
http://example.com/fillpdf/1/2-3-4 (multiple nids)
Ultimately, I think this is a more predictable and easier to use format, but I'm open to comments. The function generate a Fill PDF URL would have to be updated as well, and the old format would have to continue to be supported at least until a new branch was cut.
Comments
Comment #1
wizonesolutionsA new branch has been cut, and I definitely want to do this. It will also make access-checking a lot easier because I will have what I need in the URL.
Comment #1.0
wizonesolutionsUpdated issue summary.
Comment #2
liam morlandComment #3
wizonesolutionsComment #4
panchoI'm very much in favor of using some Symfony-style slugs instead of relying on query string parameters only.
I think we should however do some more research on the pros and cons of the different approaches.
http://example.com/fillpdf/1/2/3may work but is pretty much uncomprehensible and opaque.But how about
http://example.com/fillpdf/1/node/45(for nodes) resp.http://example.com/fillpdf/1/form/test/27(for webform_submissions)Or wait? Isn't actually the feeding entity what should be in control? So how about
http://example.com/node/45/fillpdf/1resp.http://example.com/form/test/27/fillpdf/1or as a compromise between slugs and query parameters:http://example.com/node/45?fillpdf=1resp.http://example.com/form/test/sid=27&fillpdf=1? Doesn't work out of the box for webform_submissions, but might be just what we want for Core entities.Another question would be the multiple values:
http://example.com/fillpdf/1/2+3+4(AND) resp.http://example.com/fillpdf/1/2,3,4(OR) might work, and paths used to work like that for taxonomy term listings until D6, however this feature has been removed. Views however still optionally allows "multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND)" for exposed filters.While this isn't easy do decide, I will certainly have an eye on possible solutions in the next months. Even if we could (and probably should) allow for different styles or implementations, the default route style should be well considered. At the same time it should be established before a 7.x-3.x branch is cut (or at least marked stable). So I don't know, for now I have to think about it...
Comment #5
panchoPostponing this one to #516840: Allow using a view as data source. Views integration would allow us to allowing a single entity or view as data source, so would influence how we may and might want to refactor FillPDF URLs.