On the Pineco.de site they've posted a tutorial showing you how to use the Laravel framework to generate PDFs with content provided from the system. To accomplish the content-to-PDF conversion, they make use of the dompdf library.

PDF generation is a core feature when our app contains invoicing or services that require a downloadable version of an information schema. Like in many other situations, a simple solution would do it instead of a full-featured package. Let’s see how to render PDFs easily.

Once the package is pulled in via Composer they add in a custom configuration to handle some of the basic settings including the paths to the fonts, the paper size and what DPI to use to render the final product. With that in place the post starts in on creating the custom PDF service, extending the Dompdf class and adding in a bit more Laravel-specific functionality for the service. After explaining this code they move on to updating the container to include the service via a provider and show the creation of a simple PDF controller. This controller uses the service to generate PDF output from the data in their invoice object and stream the results directly back to the client.

In a new post to his site Rob Allen shows you how he adapted a package of his own to work with a Slim framework based API to render "ApiProblem" types correctly (according to this specification).

In the API I'm currently building, I'm rendering errors using RFC 7807: Problem Details for HTTP APIs. As this is a Slim Framework project, it uses PSR-7, so I updated rka-content-type-renderer to support problem.

RFC 7807 defines a standard for sending details of an error in an HTTP response message. It supports both XML and JSON formats.

He starts with an example of the "Problem" response format that includes data for the type of error, details and links to other related objects. He points out this package from Larry Garfield that handles the actual output of the respose format but Rob needed a way to shift between JSON and XML formats too. This is where his updates to his package came in, changing it to include a ApiProblemRenderer that reads the "Accept" header of the incoming request and correctly formats the results accordingly.

As is mentioned in this new post on the Symfony Finland site, the functionality allowing the Twig templating engine to perform Angular 2 Universal Rendering.

Angular is a household name when it comes to JavaScript frameworks. They've been going through a major transition since the announcement of Angular 2. In the latest development Angular 2 will be getting PHP / Twig support for isomorphic rendering.

[...] So the Angular and the Drupal development teams have started working together to bring Universal Rendering to PHP and Twig. The details remain murky on how exactly this will be implemented (using a Node.js server or a PHP library), but a PHP library (not an extension written in C) would be the easiest option for developers.

He points out that there's also a chance that the result could be coupled to Drupal (at least at first) but hopes are that it will end up as a generic component usable in any system using Twig. The post also includes links where you can find out more information about the topic of "Isomorphic Rendering" too.

The Agile Toolkit blog has a new post today that looks at speed in PHP frameworks the their relative speed (no, there's no benchmarks here).

This question is often asked, but is never answered properly. So how to measure framework speed? Let me also explain why “scalability” is more important than general “performance”. [...] This along with a general overheads of the framework greatly contributes to the “slowness” of your project. So how can framework contribute to performance of your project?

They touch a few different ways that frameworks can help execute things a bit faster like:

• Make Fewer SQL Queries
• Selective render
• Parallelization
• Overheads
• Caching

New from the Agile Toolkit News site today, there's a new article looking at selectively rendering views in framework-based web applications, handling them as objects instead of just output.

Today – any desktop software is able to re-draw itself from a callback by operating system. However many Web Frameworks today do not keep track of objects and cannot selectively produce pieces of HTML code. I believe that ability to have control over objects on HTML pages is very essential to have in the Framework. Here is why...

He starts with a look at how desktop software handles things, then moves to the state of web rendering ("still in the 90-ties"). He talks about their better approach to things - creating a two-pass walkthrough where rendering is done on each of the objects in the page first and then those are passed to a "master parser" for overall display. A simple PHP code example is included. Creating an application with this approach makes performance, javascript integration and other templating features simpler.