Returning only content-type header from LedgerSMB::Template
With the idea to simplify our LedgerSMB::Template handler, by moving all headers (but the content-type) from there to LedgerSMB::PSGI, I went to task: In the referenced issue, you write
The template should be responsible *only* to render the content and provide a file mime type back with it. This means that the output of template->render() should ...
Assuming that "template" there corresponds to my definition of "LedgerSMB Template Engine" (concluded from the fragment of the second sentence), I really wonder what value the template engine is providing: our template processor has a render method too; the *only* thing it lacks is the content type return value. The content type can be easily added based on the extension of the processed template in a generic handler elsewhere though.
Right.
In the same paragraph, you continue
The Template MUST NOT assume HTTP, PSGI, or any other particular input/output format.
Could you have a look and https://github.com/ledgersmb/L edgerSMB/blob/master/lib/LedgerSMB/Template.pm#L540 ? I think that that achieves what you want.
Yes, though more specifically, I think if we *do not use* PSGI or output options we achieve something much better. What I want to achieve is a clearer separation of responsibility and I think this has cascading benefits through the rest of the application as well as making the logic more general.
Ok. You're proposing the return value being a pair: the expanded template and the mime-type. The current implementation is a list of headers (usually just the mime-type), the expanded template and a success/fail indicator (a triplet).
If we want to go with just the pair, how are we going to report the success/fail indicator? (In other words, how do we report error conditions?) I'll move the handling of the cache control headers currently in "render_to_psgi()" to LedgerSMB::PSGI. That's a positive outcome of this discussion for sure.
I have local work-in-progress. I've successfully moved the characterset addition to (utf-8) to all "text/" mime-types as well as the headers disabling caching when "back button disabling" is enabled, to LedgerSMB::PSGI. However, I'm trying to move the Content-Disposition headers to LedgerSMB::PSGI, but that's not quite so easy: the disposition header uses knowledge from the template (the type and name of the report). This information is not available on the LedgerSMB::PSGI level. So, how do I meaningfully name the downloaded file in this new world order? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
On Thu, Aug 31, 2017 at 10:18 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
With the idea to simplify our LedgerSMB::Template handler, by moving all headers (but the content-type) from there to LedgerSMB::PSGI, I went to task:
In the referenced issue, you write
The template should be responsible *only* to render the content and provide a file mime type back with it. This means that the output of template->render() should ...
Assuming that "template" there corresponds to my definition of "LedgerSMB Template Engine" (concluded from the fragment of the second sentence), I really wonder what value the template engine is providing: our template processor has a render method too; the *only* thing it lacks is the content type return value. The content type can be easily added based on the extension of the processed template in a generic handler elsewhere though.
Right.
In the same paragraph, you continue
The Template MUST NOT assume HTTP, PSGI, or any other particular input/output format.
Could you have a look and https://github.com/ledgersmb/L edgerSMB/blob/master/lib/LedgerSMB/Template.pm#L540 ? I think that that achieves what you want.
Yes, though more specifically, I think if we *do not use* PSGI or output options we achieve something much better. What I want to achieve is a clearer separation of responsibility and I think this has cascading benefits through the rest of the application as well as making the logic more general.
Ok. You're proposing the return value being a pair: the expanded template and the mime-type. The current implementation is a list of headers (usually just the mime-type), the expanded template and a success/fail indicator (a triplet).
If we want to go with just the pair, how are we going to report the success/fail indicator? (In other words, how do we report error conditions?) I'll move the handling of the cache control headers currently in "render_to_psgi()" to LedgerSMB::PSGI. That's a positive outcome of this discussion for sure.
I have local work-in-progress. I've successfully moved the characterset addition to (utf-8) to all "text/" mime-types as well as the headers disabling caching when "back button disabling" is enabled, to LedgerSMB::PSGI.
However, I'm trying to move the Content-Disposition headers to LedgerSMB::PSGI, but that's not quite so easy: the disposition header uses knowledge from the template (the type and name of the report). This information is not available on the LedgerSMB::PSGI level. So, how do I meaningfully name the downloaded file in this new world order?
maybe a file-name key in the return hash?
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
participants (2)
-
Chris Travers -
Erik Huelsmann