[
https://issues.apache.org/jira/browse/LABS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676906#action_12676906
]
Simone Gianni commented on LABS-306:
------------------------------------
The problem boils down to having different postprocessing. The producer is
determined as usual, resolving the url. After that, depending on the type of
producer returned and the request, correct postprocessing must be determined.
Postprocessing implies two phases : aggregation and final rendering.
Aggregation is done with templates, final rendering depends on the kind of
request.
Default postprocessing are currently two :
- For html producers, aggregate with template and serve as HTML
- For other producers, stream to output
Different post processings could :
- Alter the rendering, for example get the HTML and render it as a PDF
- Alter the aggregation, for example discard the template, or use another
predefined one.
- Alter both
Where aggregation is not possible (for example, plain resources), still it
could be possible to alter the rendering.
Now, how to divide the uri space to trigger different postprocessing.
One easy way could be to use the extension. So, for example, /this/that would
render with default, /this/that.pdf with the pdf setting.
Obviously, a problem arise when it comes to resources, cause they will msot
probably have an extension, like /this/arrow.gif . So, there should be a way to
handle this.
The simplest one is, if the extension is not a knows postprocessing setting,
then go for the resource. It works quite well, except that adding a pdf
generating system would stop serving of pdf resource.
A more complex one could be to fallback, since most probably one of the two
would not work. For example, if it does exist a /this/that, then /this/that.pdf
refers to postprocessing /this/that, and it's rather unfair to also have a
/this/that.pdf resource.
So, go for the postprocessing first if the extension is registered as such, if
that fails cause the path does not resolve to a producer, try if it is a raw
resource.
Templates should anyway be handled in some other way. Consider the "printing
version" example. The simple solution is that it discards the template, and
renders the main content in a predefined default template, trimmed down to the
bare minimum and with a print link. Eventually that template could be
customizable by the user, as it happens for HTML, opening a new problem.
Suppose I have a site with three html templates : the home page, a news/article
section and a product listing section. I probably will want to have different
templates for printing too, or for PDF, or anything else.
That opens the need to configure different templates for different
postprocessing systems that wants to give this flexibility.
So, this sums up in the following modifications :
- Give a way to add new postprocessing systems
... The simplest i can think of, adding handleEXT methods on the servlet
itself, depending on wether it accepts Producer, HtmlProducer or other effects
what kind of data it handles.
- Keep the default processing system in place
- Fallback to it after checking if applicable
- Refactor out of the servlet the template system
- Extend the template system to support multiple templates on the same
Templatable
... Also in this case, method addition could work, cause it could also force
the user to use the correct Template subclasses
... An internal storage of defined templates could offer a common background
- Eventually refactor the Template class to make it more easily extensible
... PDF templates made with PDF files? JSON templates for Ajax?
> [web] Raw "template"
> --------------------
>
> Key: LABS-306
> URL: https://issues.apache.org/jira/browse/LABS-306
> Project: Labs
> Issue Type: New Feature
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Next
>
>
> Actually the Dispatch servlet, which serves content in Magma, operates in two
> distinct ways :
> - If result is a Producer, stream it to output. This is the case for
> resources.
> - If result is an HtmlProducer, pass it to a template, which will take care
> of aggregating stuff around it and use an URLRewritingStream for proper URL
> rewriting.
> This is nice, but limitating. There are situations where :
> - We want to serve an html fragment having the advantage of URL rewriting,
> but not having a template around.
> - We want to use a different template, and force it no matter what
> - We want to use a different template and eventually different post
> processing.
> A use case for the first situation is quite simple : an html frameset for
> example, there must be URL rewriting but no template around it. Another one,
> serving an HTML fragment as the result on an AJAX call, we want the fragment
> as it would appear inside the template, but without all the template around.
> For the second situation, a good use case is a print template. There are
> already a number of methods to set the template, using the Templatable
> interface, but the innermost setting takes precedence over the outmost, whle
> in this case the opposite should happen.
> The third situation is for advanced stuff, like HTML to PDF generation
> (perfectly possible with XSLT translating to XSL-FO, or using CSS 3 and a
> postprocessor) or again more complex Ajax interactions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
