Skip to main content

View Helpers - Custom Output Parser

I was reviewing some blade view code recently and decided it was too verbose. There were some long output statements that were duplicated throughout the view and that always signals a need to refactor or come up with a better method. So I wanted to share (or at least document) what I came up with here.

First, the issue: fields stored as boolean "0/1" in the database must be output in "Yes/No" format. Plus, if the field is blank (or null), that must be reflected as well. Add to that the uncertainty of whether the production Microsoft Azure database will return a string or integer value for 1 or 0.

This problem necessitates a blade statement like:

{{ $object->property === null || $object->property === "" ? "" : $object->property == 1 ? 'Yes' : 'No' }}

Like I said...verbose!

One solution might be to create a Laravel accessor for the boolean field in the model. But that would mean that if I want the actual boolean value, I'd have to add a getOriginal() method to the value to bypass the accessor. While this is okay, it can wreak havoc when other developers are trying to access a property and they don't realize there is an accessor in the model. Also, I'd have to write a separate accessor for every boolean property on every model in my project.

Instead, I created a Parse class in my app/Helpers folder that can perform a number of useful functions for my view. You can view this class here.

Then I added the Parse class to my config/app.php file under 'aliases':

        'Parse' => App\Helpers\Parse::class,

Here's the above statement simplified using the parser helper:

{{ Parse::yesNo($object->property }}

But because sometimes specifications change and form questions are asked in an opposite way from what was originally specified, I made a reverse parser, where a boolean 1 actually means 'No':

{{ Parse::noYes($object->property }}

Additionally, sometimes Yes and No don't cover every usage for a boolean field, so I made it possible to pass in other strings to replace 'Yes' and 'No':

{{ Parse::yesNo($object->property, 'Awesome!', 'Awful') }}

I hope this helps someone else out there looking for cleaner views! 😃

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...

Salesforce Apex: Replacing and/or Removing Apex Classes

Working with code within the constraints of Salesforce's workflow can be a challenge.  First , you have the restriction on changing anything in production.  Second , you have the requirement for 75% or greater unit test coverage.  Third , you have the fact that certain metadata cannot be pushed to production through a changeset (which means the only way to sync record IDs is by re-deploying the development environment from production). Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI .  The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production.  And (here's the kicker)...sometimes it doesn't work because...reasons. So let's start with the workflow of a f...

PHP empty()

The PHP "empty($var)" function (or language construct) is a handy function that I use a lot.  It replaces all of the following checks: isset($var) $var !== 0 $var !== 0.0 $var !== "" $var !== "0" $var !== null $var !== false count($var) > 0 // if array This is particularly useful for integers, but can also be useful for checking strings and floats.  It replaces a bunch of conditions you'd otherwise have to type. I've had some disagreements over my frequent usage of empty().  There are those who believe explicit value checks are important to code readability.  My response is to ask why a longer line of code is any more readable.  There are also those who consider '0' to be non-empty, in which case the use of empty() would not be appropriate.  However, the majority of the time when you use empty(), it will be to check a MySQL ID value, which will (should) always be greater than 0. Consider the following example: if...