Skip to main content

Props for Laravel's Blade Templating

While perhaps not as powerful as the Twig template engine, Laravel's Blade template engine does pretty much everything you're likely to need done in your view templates and it does it with more intuitive syntax. So I wanted to give it some props here that it very much deserves.

To boil Blade down to its very basics, there are three essential construct types you need to know:

  1. {{ $var }} - output a variable
  2. {!! $html !!} - output some HTML (previously sanitized, we hope)
  3. @something - the equivalent of the if/else/foreach statements in PHP
Basically, any PHP statement you need to use will work within the body of these three constructs. So here are some control flow statements in Blade:

@foreach ($companies as $i => $company)
@endforeach

@if ($something === null)
@endif

And here are three versions of an echo statement that all work the same:

{{ $name === null ? 'Unknown Name' : $name }}

{{ $name or 'Unknown Name' }}

{{ $name ?? 'Unknown Name' }}

(Note: this last statement requires PHP7+)

Why is all this important? The main benefit here is in keeping your output statements very simple. After all, you want your view template to be all about the HTML, not the underlying code.

As an example of a real-life benefit, here's an issue I ran across recently:

When beginning a project, the client specified that they needed to know whether a person owned or rented their property. So I created a boolean field called "own". If not owned, then rented...right?

Nearing project completion, the client tells me that they need to also know if the question wasn't answered.  So now we have three states...own, rented and null.  Rather than ditch my boolean field, I can take advantage of the nullable property of the database field.  Unfortunately, the backend database and O/S that hosts this application differ from development to staging/production, so I can't guarantee that the model's value will return NULL, a boolean, an integer or string.  Thankfully, all I have to do is update my blade statement, like so:

{{ $own === null || $own === "" ? "" :  $own == 1 ? "Own" : "Rent" }}

Smooth...

Comments

Popular posts from this blog

jQuery noUIslider Pip Label Customization

Recently, I was tasked with creating a slider element for a user to select their credit rating, of which the user can select from among: 'Poor', 'Fair', 'Good', 'Excellent' and 'Not Sure'.  Several problems presented themselves here: A drop-down box would be better, but that's not what the requirements specified. I already have several numeric sliders on my page and I want them all to match. I selected the jQuery noUi Slider library to create the numeric sliders. noUi Slider does not support string values - only numeric values. The "pips" (slider scale/labels) also does not support string values. Since the solution involved shifting my mindset, I wanted to document it here for future reference and maybe to help someone facing the same requirements. Here's my solution: Since there is really no numeric correlation to credit score (especially considering one of the options is "Not Sure"), I will just u...

How to Create a new Case Record Type in Salesforce

Here are the specific steps for adding a case record type. Some steps may vary by organization but the process should be pretty similar to what is shown here. 1) Create a new page layout 2) Add any new case statuses to picklist 3) Edit case statuses that should indicate case is "closed" 4) Add any new case types to picklist 5) Add any new case reasons to picklist 6) Add any new case origins to picklist 7) Add any new fields to case object 8) Under Record Types, ensure the picklists have the correct values (i.e. - Reason/Type/Origin) 9) Within the Type field, edit "Reason" field dependencies matrix and add new reason(s) to types 10) Create a new support process (if not reusing an existing one) 11) Create the new record type (enable for all profiles) 12) Finalize the page layout (if needed) and check "Default" in Case Assignment checkbox under Layout Properties 13) Create approval queues (if needed) 14) Set up approv...

Java...Still Sucking Hard, Compared to Other Languages

I know there are a bunch of Java devotees out there.  I frequently have them evangelizing the language to me as a "strongly-typed" language that is so much better than loosely-typed languages, like PHP.  So here is something that just came up for me and I'd like to ask all those devotees WHY they like the type enforcement. Here's a bit of code to store a random integer as a string in PHP: $myString = rand(5); And now...the Java version: String myString = String . valueOf ( Integer . valueOf ( Math . random () * 10000 )); I get it...you need to keep your phony-baloney job and writing more  code and making it more complicated can help you keep it out of the hands of less "intelligent" programmers. As for myself, I will always prefer a language that lets me write shorter, more eloquent code and get my applications built faster.  But then...maybe I'm just simple.