Freek Van der Herten has a post for the Laravel users out there showing how to use custom HTML components in your Blade views making use of this package.

Today we launched our newest package called BladeX. In short this package provides you with an easy html like way to render custom html components in your Blade views. In this blogpost I'd like to introduce the package to you.

He starts by describing an example application where reusable components could be helpful (things like alert messages, form components and layout parts). He then shows how to create a component for an alert message that can be used via the @component functionality in Blade as a sort of "include and use" call. He shows how to pass in variables, use slots, and prefix components. He wraps up the post going "under the hood" and showing how it works via a service provider and how they made the package (and why).

On the Sticher.io blog Brent has written up a post covering the use of MySQL views in Eloquent, the database ORM that's included with the Laravel framework.

MySQL views are a way of storing queries on the database level, and producing virtual tables with them. In this post we'll look at why you want to use them and how they can be integrated in Laravel with Eloquent models.

If you're already convinced of the power of MySQL views, or just want to know how to implement them in Laravel, you're free to skip ahead.

For those not familiar with the concept of "views" in MySQL, he spends a little time explaining what they are and what benefits they bring to the table. This includes a code example of a migration to create one and how something similar could be achieved with event hooks on a Laravel model. He then gets into the use of the views with Laravel, refactoring a more complex SELECT query into a view and creating/removing it using the same migration methods as any other table in the database.

On the Laravel News site they've posted a quick tutorial showing you how to change the path to views in a Laravel-based application.

In response to our post yesterday about Laravel 5.7 Resources Directory Changes, a reader mentioned that they would prefer to have their application views outside of the resources folder.

I thought I’d write up how you can customize the view path; it’s effortless with Laravel!

The change is made in the views.php configuration file, updating the value for the paths setting. You can point it to a single location (like the application path or resource path) or you can set multiple to tell the framework to search for the view in either. The post ends with a mention one thing to keep in mind about generating views and their location (and moving them around).

Rob Allen continues his series of posts covering the use of PHP on the OpenWhisk platform. In his latest post he shows how to usr Fractal as the view layer for your application (as installed via Composer). Fractal is a project from the PHP League that "provides a presentation and transformation layer for complex data output, the like found in RESTful APIs, and works really well with JSON."

When writing an API, it’s common to produce an output that conforms to a known media type such as JSON API or HAL, etc. I’m a strong believer that even though I’m writing an API, my application has a view layer. It’s not the same as building an HTML page, but you still need to separate out the code that creates the structured output from your model layer. For a couple of APIs that I’ve written recently, I’ve used Fractal for this.

He starts with some example code showing how to use Fractal to transform data that's come from his datasource. This includes both the script to use the Manager and the class defining the "transformer" for the todo data. He then moves this over and integrates it with an OpenWhisk application, making use of the dependency injection container to create transformer and manager instances. His final example shows this setup in action as the result of a call to fetch all current todo items.

On the Laravel News site there's a new post covering a refactoring of view handling that's possible with recent versions of the framework: using view components instead of view composers..

In software development, one of the “best practices” is to create reusable code that can be implemented in different parts of your application if needed. [...] View composers allow you to move the logic outside your controller and pass the data to the specified set of views. [Using view components instead of composers lets you] reuse complex components using dynamic data on any view within your application.

To help illustrate the difference they set up a scenario of a blog with a "highlights" sidebar based on data from an API response. With view composers you could extract this logic out of the controllers and add it more automatically to the view itself. They point out that this can work for a majority of the situations there's another method that is even more flexible: a reusable component implemented directly on the view. He provides the complete code showing an examples of this components, including a custom Blade directive.

On the Laravel News site there's a tutorial posted showing you how to use Blade's View::first functionality to dynamically show a template if it exists.

When building dynamic components or pages sometimes we want to display a custom template if it exists or otherwise fall back on a default one.

[...] We can solve this problem with a series of conditionals or by using view()->exists() to check if a custom template exists or not, however, Laravel 5.5 brings us a better and more elegant way.

A screencast of the functionality in action is included as well as a text-only version with code samples showing the previously used "if view exists" check and the refactor to use View::first instead.

This dynamic view loading feature was added to Blade in Laravel v5.5 and is a great way of keeping your controllers simple by avoiding extra conditionals when dealing with dynamic templates.

Sebastian De Deyne has a new post to his site showing the Laravel users out there a method for theme-based views in their applications using vendor namespacing in a multi-tenant environment.

I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.

Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.

[...] There aren't any huge issues here, but all together it feels like we should be able to do better. There are a few strategies to clean this up, but I just want to talk about vendor namespaces today.

He gives an example of a view setup that makes use of the current client/customer's namespace to define the path to the template. He found this leading to a lot of redundancy and figured out a better way: using namespaces. Namespacing is mainly made for package development but can be use here to create a "theme" namespace. This namespace can then be defined once and reused across the application without the need to manually build the template location string every time.

Freek Van der Herten has a quick post to his site with a tip about simplifying presenters in your Laravel based application. The "presenters" here are in relation to this package and how it helps with the output of the application.

In the Laravel template that we use to kickstart all our client projects at Spatie, I recently changed the way we handle presenters. Instead of using Jeffrey Way’s popular presenter package we now use simple traits. In this post I want to give some background on that change.

He gives a quick "crash course" on presenters for those not familiar with the concept and how it helps to keep view logic out of places like models and controllers. He briefly describes a presenter class that would return the "first name + last name" combination and what the code could look like. Then it's just a matter of using that trait (the class mentioned just before this) and a new magic property is defined to use in the view.

On the SitePoint PHP Blog Reza Lavaryan has shared a "quick tip" about making it easier to pass data out to the views in your MVC application. It relates more specifically to when you have a lot of values to pass out rather than just a few bits of data.

In MVC based architectures, working with template engines is an inevitable part of the development routine. It usually goes like this: we prepare and pass the data to the view. In the view, we print them based on our layout design.

[...] There are times, however, when the number of variables might be much higher than this: ten or more. In that case, we’ll have a tall list of variables (as an associative array), being passed to the respective template. It gets messy and unreadable quickly. If only there was a way to just list what we need by name, and have PHP take care of the rest for us. Well… there is!

The example shows how to use the compact function built into PHP to grab values from the current scope and return them as an array. Unfortunately it does loose the array keys with this method, so they propose an alternative with the get_defined_vars function and some simple key handling to return a more correct version of the array.

The SitePoint PHP blog has another post in its series about working with Drupal 8. In this new tutorial author Daniel Sipos talks about theming views in the content management system and introducing custom style plugins.

In this article, we are going to look at how we can create a custom Style plugin for Views in Drupal 8. We will use the Bootstrap tab markup as a goal and implement a tabbed output for our View results. In the View configuration, the Style settings will allow us to specify which field will be used as the tab navigation copy, leaving the rest of the fields shown in the respective tab panes. Basically, each View result will represent a tab – so this example is not suited for Views which have more than a few results. The main goal is to illustrate how we can create our own Views Style plugins in Drupal 8.

He starts by talking about Style plugins - what they are and where they fit in the application execution flow. He then walks you through the creation of the custom style plugin to integrate the Bootstrap tabs. This also includes the creation of the theme and the matching template to build out the tab markup.