Developer Thought Stream

What is "touches"?  Well, anyone familiar with Linux/Unix is going to be familiar with the concept of "touching" a file.  Touching a file sets the "last modified" timestamp (or creates the file if it doesn't exist).  Knowing when a file was last modified can be very important for version control. Laravel has something similar for its model relations.  For example, lets say there is a club with many members.  When a member joins, leaves or gets a new role in the club, you might contend that the club has changed.  In terms of Laravel, you would want the club table's "updated_at" timestamp to reflect that change.  Enter the "touches" property... To make the magic happen in Laravel, you simply need to define the parent relationship and add it to the touches property like so: <?php class Club extends Model { /** * Touches (touch parent model when this model changes) */ protected $touches = [ ...

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

// A little lesson on naming conventions in Laravel Eloquent: // Table 1: product_variants - variations of a certain product // Table 2: variant_usage - pivot table between product_variants and usage // Table 3: usage - the various product variant uses // Usage - returns all usages for the ProductVariant model public function usage () { return $this -> belongsToMany( ' App\Usage ' , ' variant_usage ' , ' variant_id ' , ' usage_id ' ); // Note: the 2nd/3rd/4th parameters wouldn't be necessary... // ...if the 'variant_usage' table were named 'product_variant_usage' // ...or if 'product_variant' were simply named 'variant' // ...(i.e. - product_variants --> product_variant_usage --> usage) // Also Note: the ID parameters are the connecting points in variant_usage // ...(i.e. - product_variants --> {variant_id ...

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

So...I just discovered a "gotcha" with Eloquent relationships that I wish I had known when I created my migrations and data files.  So this would be good for other developers to know in advance as well.  The essence of the problem has to do with the potential name conflict between an eloquent property and a relationship method.  Here's a look at the problem I ran into: 1) I have a "states" table with the following columns: id (auto-numbered), name, abbreviation. 2) I have a "companies" table with the following columns: id, name, address, city, state, zip. Notice that I didn't use a "state_id" column in my "companies" table.  Instead, I insert the state abbreviation and label it as "state".  I made this decision because I fairly often run queries directly against tables and I want to avoid having to type out the JOIN statement for a simple, 2-character field. So that's all fine except when I want to create a ...