View Handlers

[Jamie Rumbelow]

Did you guys view that screencast I sent you (http://railscasts.com/episodes/153-pdfs-with-prawn) and if so what did you think/what can we apply to recess?

 

Jamie

 

Jamie Rumbelow Designer / Developer / Writer / Speaker

http://www.jamierumbelow.net | +44 (0)7956 363875 | jamie (at) jamierumbelow (dot) net

 

[KevBurnsJr]

Definitely an interesting talk. I liked their use of file extensions
to denote output type and rendering method.

.pdf.prawn
.html.php
.html.smarty

Now I understand why all my scaffold view templates in rails are
suffixed .html.erb

- Kev

[Kris Jordan]

Jamie -

Thanks for this screencast. Finally got a chance to watch it (it was down when I tried to watch earlier in the week).

This is *very* in line with what I'd like to see in Recess. I've spent some more time learning about content-negotiation best practices. As it turns out I don't think we're far off from being able to have this functionality.

The most complicated component is efficiently parsing and handling the HTTP Accepts header. The accepts header gives a client a way of specifying the desired mime-type with a prioritized list (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). The general problem is that the for any URI a client requests the list can expand with wildcards (in fact, IE Accepts */* which expands to any available mime-type representation). On the other side, for any given URI, Recess has a finite list of mime-types it can respond to but, supposing a system based on filename extensions (which I really, really like) as shown in the Railscast, knowing that list is very expensive because it involves knowing which files with certain extensions exist on disk. The few PHP implementations I've seen for mime-type selection require full-knowledge of both expanded lists. I think we can do better by caching and/or lazy expansion of both lists (i.e. a back-and-forth "client: what's your most preferred type?" pdf, "view: can you provide a pdf? no." "ok, client: what's your next most preferred type" html, "view: can you provide html?" yes). Started some code on this I'd like to move a bit further with before pushing to Github.

A problem I didn't have a concrete answer to was "how are multiple view/template providers handled (i.e. prawn or smarty)". In the screencast you see .html.erb and .pdf.prawn. Would a similar convention make sense in PHP? .xhtml.smarty? .json.php? This would mean there could only be one View provider that uses the .php extension which seems restrictive. Using 3 extensions (i.e. product.pdf.prawn.php) seems excessive. What are your thoughts?

Another question that interests me is how Rails chooses which provider to use when they respond to the same formats (i.e. order.pdf.erb / order.pdf.prawn)?

Need to run but I've got some thoughts on the input-side of the problem too (flexibly supporting different content-types in put/post data). Will send soon.

Kris

[Jamie Rumbelow]

Kris,

 

Yeah, using three extensions does seem excessive, but I reckon it wouldn’t be a problem, or even necessary. I don’t think that the provider should be chosen solely on the extension – I think it’d be a better idea for a provider to accept different mime-types and parse it through that.

 

For instance, if we had a provider called TemplateProviderPhp (which would map to *.php, as TemplateProviderPrawn would map to *.prawn), the code could look something like so:

 

class TemplateProviderPhp extends TemplateProvider implements ITemplateProvider {

 

                public function __construct() {

                                $this->registerHandler(‘html’, ‘text/html’);

                                $this->registerHandler(‘pdf’, ‘application/pdf’);

}

 

                public function html($file) {

                                //Buffer...

                                Ob_start();

 

                                //Load and evaluate the file

                                include($file);

 

                                //Catch the output

                                $output = ob_get_contents();

                                Ob_clear_end();

 

                                //Pass back to recess

                                $this->render($output);

                }

 

                Public function pdf($file) {

                                //Create new PDFRender object

                                $pdf = new PDFRender();

 

                                //Buffer...

                                Ob_start();

 

                                //Load and evaluate the file

                                include($file);

 

                                //Catch the output

                                $output = ob_get_contents();

                                Ob_clear_end();

 

                                //Pass back to recess

                                $this->render($output);

                }

 

}

 

This is just a simple example code, but as you can see, each template handler (noted by the second extension, in this example .php) can hold multiple mime-types, which it can then output in different ways (in this example, both .html and .pdf are recognized, so you could load .html.php and .pdf.php into the provider).

 

The method would be in the same scope as the view, so you could include variables, such as a $pdf object, shown in the above example. It is then the provider’s job to  register the extension with a specific mime-type, as we did above. When Recess is looking for the right provider to use, it looks through TemplateProvider’s array of all registered formats and chooses based on that.

 

Jamie Rumbelow Designer / Developer / Writer / Speaker

http://www.jamierumbelow.net | +44 (0)7956 363875 | jamie (at) jamierumbelow (dot) net