Liam Hammett has written up a post to his site covering the use and creation of helpers for Laravel's Blade templating. He shows the use of a package he's created to help make using them with custom callbacks simpler.

Laravel’s Blade templating engine offers a ton of convenient directives you can use to make your view files beautiful and abstract anything that may be too complex or verbose to live inside HTML. It even gives a really handy way to add your own custom directives using the Blade::directive(…) method.

However, the callback in custom directives only receives a single parameter?—?the raw string expression from the view file. [...] As this seems to be the most common use case, I put together a package that attempts to help make these helper functions that little bit easier to define without the boilerplate of returning the string or having to consider what an expression may be when creating a directive.

In his package he introduces a new method that defines the name of the method and the name of the function to call. This second option can also be a custom callback function, making it even more flexible.

In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

Tomas Votruba has a new post to his site about an update that's been made on Statie, a static site generation tool, to support Twig templates natively.

Statie supports YAML and Symfony Dependency Injection for some time. But you wanted more! You wanted Twig. Sculpin and all the other PHP generators have it.

So there you go! Enjoy.

He shares the three steps needed to set up a sample Twig template and have it rendered as easily as the normal Statie templates:

1. Prepare Layout _layouts/default.twig
2. Create Template contact.twig
3. Enable Twig

Template contents and configuration change examples are included as well as instructions on how to update to this latest (v5.4) version. He includes tips on the naming and locations of the template files as well as a mention of his package to help translate from Latte to Twig templates.

Tomas Votruba has a post to his site sharing a method for translating Latte templates to Twig templates with the help of the Simplify tool.

Statie - a tool for generating static open-sourced website like this blog or Pehapkari.cz - runs on YAML and Symfony DI Container. That way it's easy to understand by the PHP community worldwide.

But there are some pitfalls left. Like templates - being Latte the only one is a pity. Twig is often requested feature and one of the last big reasons not to use Statie.

Well, it was. Statie will support both Twig and Latte since next version. Are you a Twig fan? As a side effect, I made 27 regular expression to handle 80 % of the Latte to Twig migration for you.

He starts with a bit of explanation of how to the project started and his goals ("investing 5 hours to automate 30-minutes manual work under 10 seconds, so no-one else will have to do that ever again"). He covers the installation of the Symplify tool and how to execute the latte-to-twig-converter on a directory of Latte templates. He also provides some snippets of code you can use if you want to reverse the process and go from Twig to Latte.

On the Laravel News site they've shared a list of five useful Blade directives that you may not have known about. Blade is the templating language included with the Laravel framework by default.

We’re going to look at five Laravel Blade directives you can use to simplify your templates, and learn about some convenient directives that make solving specific problems a cinch! If you’re new to the framework, these tips will help you discover the excellent features of Blade, Laravel’s templating engine.

The five on their list provide functionality to:

1. Check if the user is authenticated
2. Check if the user is a guest
3. Include the first view if it exists or includes the second if it doesn’t
4. Include a view based on a condition
5. Include a view if it exists

Each one comes with example code showing it in use and a bit of explanation behind its use.

The StarTutorial.com site has continued their series covering common design patterns and their implementation in PHP. In their latest article they cover the Template Method pattern.

[This pattern] defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

In their example, they have two workers that have different schedules but with one difference. Instead of having implementations that differ widely between the two workers (represented by classes) they refactor the main class and allow for a doWork method to be defined in the child. This makes the parent class a sort of "template" for handling the processing with the child filling in the blanks.

On the Pineco.de site they've posted a tutorial showing how to create a lightweight breadcrumb system for use in a Laravel application. It makes use of a "view composer" to help translate the current path into a matching "crumb".

Breadcrumbs are important in web applications. But most of the time, it’s not the easiest to track the different levels in your URL and generate breadcrumbs from it. Now we give it a try with a simple yet elegant solution.

The post starts by describing the basic concept and the article that inspired their finished product. They needed a dynamic solution that could translate the URL to a breadcrumb list. They created an array with a crumb-to-URL relationship and made use of Laravel's view composer handling to create the collection of crumbs from the current request information. Finally they include the partial view that can be used to render the results, looping through them and outputting each as a link.

On the CloudWays blog there's a tutorial posted that walks you through the beginning steps to create a Symfony + Vue.js application with a Symfony 4 application.

As a PHP developer who uses Symfony regularly, I have had a hard time choosing from the numerous JavaScript frontend frameworks available in the market. I had to pick one of the top-rated JavaScript frameworks including Angular, React, Vue and Aurelia.

[...] In this article, I will go through the process of enabling and configuring Vue.js within Symfony applications. Part of this process is covered in the official Symfony documentation.

The tutorial starts by answering the "Why Vue?" question and why frontends are important. He then gets into some of the prerequisites and the steps to create the application:

• creating the Symfony 4 application via Composer
• adding a default controller and route
• making a default Vue.js template via Twig
• pulling in Vue.js and its requirements via yarn
• creating the Vue Component

The end result is a simple page that shows the component in a Bootstrap-themed page.

On the Laravel News site there's a new post sharing some of the new Blade directives coming in the 5.6 version of the Laravel framework.

Laravel 5.6 will include two new form blade directives for cross-site request forgery (CSRF) and HTTP method input, thanks to Taylor Otwell.

The new CSRF handling replaces the previously used format with a simple @csrf tag in the Blade template (inside of the form). The other is related to the method used to submit the form. The new addition allows you to submit the form via something other than POST using the method_field function.

On the Symfony Finland blog there's a new tutorial posted sharing the results of their effort to get React.js to play nice with Twig, a popular PHP templating library, via a server-side generated template.

React.js is a JavaScript view library that allows developers to create interfaces is a structured way based on a hierarchical component structure. React can either create the DOM structure from scratch, or attach to an existing one rendered by the server to speed up the first load.

If you create Twig templates that match the React rendering, you can take advantage of this feature without a complicated rendering setup.

While there were other methods created to try to solve the problem (rendering the React.js template on the server side) they show a better way via React.js 16 and Twig templates. Code is included showing how to create a simple React application, and how to hook in Twig via a "hydrate" call to pull in the content. React.js has a bit of an issue by default but a little extra work on the Twig side fixes that (see the post for the solution on that one).