[MAGNOLIA-1977] Paragraph renderer should be able to interact with JEE request and response objects Created: 20/Dec/07 Updated: 23/Jan/13 Resolved: 21/Dec/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | templating |
| Affects Version/s: | 3.5.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Keith Childers | Assignee: | Philipp Bärfuss |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows 2003 SP2, Tomcat 6.0.14, JDK 1.5.11 |
||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
In attempting to integrate custom applications developed in ColdFusion and PHP into our magnolia 3.5 setup, we created paragraph templates of a custom "cfm" and "php", each written in its respective scripting language. These templates and their dialogs wrapped the ability to embed an application of the same type as a paragraph within the magnolia-rendered layout. This is nice because it allows us to place multple applications written in different languages in the same page. It is also nice that any code error encountered in a paragraph template doesn't halt execution of the rest of the page, and in fact displays the stack trace of that error as content for troubleshooting purposes and allows us to try-catch errors within the application rather than having to deal with exception handling at the page level. However, a problem arises when your applications need to be able to access the request object from the main JEE page request and write things into that object for processing later on in the request, or to be able to write to the response object for header insertion, for instance if the application were going to stream bits with a custom mime header to serve a file from binary storage, or to insert a redirection header. Currently, it seems that the pluggable templating mechanism doesn't allow the paragraph templates to have write access to the request or response at the page level. I also haven't figured out how to get read access to the page request object from a paragraph without explicitly passing a reference to it into the include. One of our developers customized several classes in the info.magnolia.context package to be able to override this behavior at a paragraph instance level by setting a custom property (isApplication) on the paragraph node in the JCR. He also changed JSPParagraphRenderer class in the templating module to work with these customizations. It seems the work he did no longer works in 3.5 and we'd love to see the functionality he developed added as some sort of optional switch (whether at a root config or node property level, doesn't matter) in the core application. I have attached source for the changes he made. Thanks for your consideration! |
| Comments |
| Comment by Keith Childers [ 20/Dec/07 ] |
|
Forgot to include the modified JspParagraphRenderer source |
| Comment by Philipp Bracher [ 21/Dec/07 ] |
|
In any place of the request porcessing you can get the objects through the magnolia context ((WebContext)MgnlContext.getInstance()).getRequest() The API is not using request and response so that the rendering can be used in other scenarios (testing, sending email, ..) |