Skip to main content

A Lesson from WordPress

As much as WordPress is a code disaster, there are still a few good practices and lessons that can be learned from it.  One of those practices that I've come to appreciate is the idea of a "slug", which is basically a URL, DOM ID and database key-friendly field in a table.

So for example, if you have a Products table with a product number, name and description, you may find that none of these fields are appropriate to use as a DOM ID but you may need a DOM ID to do some page automation.  This is a good time for a "slug"!

id   slug      product_number   name               description
--   -------   --------------   ------------       -----------
1    widgetT   PN-409A 1        Widget Thing       A thingy widget.
2    widgetS   PN-409B 5        Widget Stuff       Stuff for a widget.
3    thingyN   TH-655Z ABC      Non-widget Thing   Thing with no widget.

Now we have a unique, DOM-friendly ID that we can use in our HTML:

<a href="#" id="{{ $product->slug }}" onClick="addProduct({{ $product->slug }}">

 <script>
    function addProduct(slug) {
        $('#' + slug).css('color', '#ccc');
    }
</script>

I find this to be a lot cleaner and intutive than:

<a href="#" id="product{{ $product->id }}" onClick="addProduct({{ $product->id }}">

 <script>
    function addProduct(pid) {
        $('#product' + id).css('color', '#ccc');
    }
</script>

If you ever look at the page source, it is handy to have the ID indicate the actual product.

Plus, you can use that slug for more SEO-friendly URLs:

<a href="/product/{{ $product->slug }}">

Result:  http://www.mysite.com/product/widgetT

Comments

Post a Comment

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
Post a Comment
Read more

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
Post a Comment
Read more

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
Post a Comment
Read more