Here are some gists that tackle these concerns:

Caching Behavior (using ASP.NET Core IDistributedCache):

For caching, I’m using a separately defined CachePolicy similar to a FluentValidation Validator class.

Fallback Behavior (using Polly):

For Fallback and Retry behavior, I’m using separate interfaces IFallbackHandler and IRetryableRequest to get the behavior.

Retry Behavior (using Polly):

These can all be combined as well and work based on the order they’re registered in Startup.cs. In my case, I want my main Handle method to retry, then, optionally, fallback to my HandleFallback, then finally cache the result based on the defined CachePolicy.

I’m debating between using separately defined classes/policies (like FluentValidation Validators) vs. making Handlers implement the interfaces to get the behavior. On one hand, if they’re separate, I could move the Cache, Fallback and Retry policies to separate files, folders, etc. and keep my main MediatR handlers very lean and clean. If you want to see them in the same place, you could put them in the same file like many of Jimmy Bogard’s examples with Validators, etc. But if the files get too big and you want to separate them out, you could do that. However, with Retry and Fallback, it’s kind of nice seeing that with the main request handler.

Of course, all this gets wired-up and registered in Startup.cs. I’m using Scrutor to aid in discovery my Caching, Fallback and Retry policies. See below.

What do you think? Which approach do you prefer? Let me know in the comments.

The post Cross-Cutting Concerns with MediatR Pipeline Behaviors first appeared on Adam Anderly.

This trait is useful when you have dates on models that you need to display in the user’s timezone.

<pre class="lang:php decode:true">// app\Traits\UserTimezoneAware.php
namespace App\Traits;
trait UserTimezoneAware
{
    /**
     * The attribute name containing the timezone (defaults to "timezone").
     *
     * @var string
     */
    public $timezoneAttribute = 'timezone';
     
    /**
     * Return the passed date in the user's timezone (or default to the app timezone)
     *
     * @return string
    */
    public function getDateToUserTimezone($date, $timezone = null)
    {
        if ($timezone == null) {
            if (Auth::check()) {
                $timezone = Auth::user()->timezone;
            } else {
                $timezone = Config::get('app.timezone');
            }
        }
        $datetime = new DateTime($date);
        $datetime->setTimezone(new datetimezone($timezone));
        
        return $datetime->format('c');
    }   
}

</pre>

It’s a simple trait you can drop onto one of your eloquent models to add timezone support like so:

<pre class="lang:php decode:true">// app\Models\User.php
namespace App\Models;

use App\Traits\UserTimezoneAware

class User
{
    use UserTimezoneAware;

    public function getLastLoginAttribute()
    {
        return $this->getDateToUserTimezone($this->attributes['last_login']);
    }
}
</pre>

Now when you access the $user->lastLogin attribute anywhere in your app, you’ll get the date in the user’s timezone.

The UserTimezoneAware trait expects the model to have a timezone attribute. If your column/attribute is named something other than timezone simply override the $timezoneAttribute property on the UserTimezoneAware trait.

<pre class="lang:php decode:true">namespace App\Models;

use App\Traits\UserTimezoneAware
 
class User
{
    use UserTimezoneAware;

    public $timezoneAttribute= 'time_zone';
}</pre>

Enjoy!

The post Laravel User Timezone Aware Trait first appeared on Adam Anderly.

This first one I use quite often.

// app\Traits\HasGravatar.php
namespace App\Traits;

trait HasGravatar
{
    
    /**
     * The attribute name containing the email address.
     *
     * @var string
     */
    public $gravatarEmail = 'email';
    
    /**
     * Get the model's gravatar
     *
     * @return string
     */
    public function getGravatarAttribute()
    {
        $hash = md5(strtolower(trim($this->attributes[$this->gravatarEmail])));
        return "https://www.gravatar.com/avatar/$hash";
    }

}

It’s a simple trait you can drop onto one of your eloquent models to add gravatar support like so:

// app\Models\User.php
namespace App\Models;

use App\Traits\HasGravatar

class User
{
    use HasGravatar;
}

Now you can do something like this in your blade views:

<img src="{{ Auth::user()->gravatar }}">

And you’ll get the gravatar.com URL you’re expecting. No need to create a gravatar column, variable, method, or anything else.

The HasGravatar Trait expects the model to have an email attribute. If your column/attribute is named something other than email simply override the $gravatarEmail property on the HasGravatar trait.

namespace App\Models;

use App\Traits\HasGravatar

class User
{
    use HasGravatar;

    public $gravatarEmail = 'email_address';
}

Enjoy!

The post Useful Laravel Model Traits: Gravatar first appeared on Adam Anderly.

Hence, the Transformable trait was born. It’s a simple PHP trait that you drop into your model and then override the $transformation_map property to specify your consumable model attributes.

Here’s an example:

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use App\Traits\Transformable;

class Group extends Model
{
    use Transformable;

    protected $transformation_map = [
        'Group_ID' => 'id',
        'Name' => 'name',
        'PublicGroup' => 'public',
    ];
}

A quick explanation: we’re importing the Transformable trait (which I’ll cover shortly) and then we’re providing a database column name-to-consumable attribute name mapping. That’s it.

A consumer of this model will not see the underlying database column names on the left hand of the mapping such as “Group_ID”, “Name”, or “PublicGroup.” Instead, they’ll see the names on the right hand side: “id”, “name” and “public.” In essence, it’s a simple transformer. Here’s an example usage:

use App\Models\Group;

class GroupsController
{
    public function index()
    {
        return Group::all();
    }
}

With a call to the above GroupsController@index method, we’d end up with the following JSON:

[
    {
        "id": 1,
        "name": "Group 1",
        "public": "0"
    },
    {
        "id": 2,
        "name": "Group 2",
        "public": "0"
    }
}

Additionally, we can create the model specifying the consumable attribute names (not the database column names):

$group = new App\Models\Group(['name' => 'Group 3', 'public' => true]);

// Calling this
$group->toJson();

// Will yield this
{
    "id": 3,
    "name": "Group 3",
    "public":"1"
}

The magic of this is in the Transformable trait. Normally, to achieve this, we’d have to specify the $visible and $appends properties on our model and provide get and set mutators for each attribute mapping. Instead, with Transformable, we simply provide the $transformation_map and the Transformable trait takes care of the rest.

It does this by overriding several methods of the Eloquent model that determine if get and set mutators exist to include checking the $transformation_map property. This is how it can return you an instance of your model as well as create an instance of your model with the consumable attribute names without you needing to specify the source database column names.

I’m working on an enhancement to Transformable to allow queries (i.e. where* methods) on the models so that you can query with the consumable attribute names and not the database column names. As soon as I wrap up those changes, I’ll look at making this a composer package.

Here’s the entire trait implementation:

namespace App\Traits;

use Illuminate\Support\Str;

Trait Transformable
{
	protected $transformation_map = [];

    /**
     * Determine if a get mutator exists for an attribute.
     *
     * @param  string  $key
     * @return bool
     */
    public function hasGetMutator($key)
    {
        return $this->keyExistsInTransformationMap($key) || parent::hasGetMutator($key);
    }

    /**
     * Determine if a set mutator exists for an attribute.
     *
     * @param  string  $key
     * @return bool
     */
    public function hasSetMutator($key)
    {
        return $this->keyExistsInTransformationMap($key) || parent::hasSetMutator($key);
    }

    /**
     * Get the value of an attribute using its mutator.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return mixed
     */
    protected function mutateAttribute($key, $value)
    {
        if ($this->keyExistsInTransformationMap($key)) {
            return $this->{$this->getTransformationMapInverse()[$key]};
        }
        return parent::mutateAttribute($key, $value);
    }

    /**
     * Set a given attribute on the model.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return $this
     */
    public function setAttribute($key, $value)
    {
        if ($this->keyExistsInTransformationMap($key)) {
            if (method_exists($this, 'set'.Str::studly($key).'Attribute')) {
                parent::setAttribute($key, $value);
            }
            $key = $this->getTransformationMapInverse()[$key];
        }
        return parent::setAttribute($key, $value);
    }

    public function keyExistsInTransformationMap($key)
    {
        return array_key_exists($key, $this->getTransformationMapInverse());
    }

    public function getTransformationMapInverse()
    {
        return array_flip($this->transformation_map);
    }
}

This could certainly be enhanced further to support casting to/from datatypes and supporting compound properties via a Closure or similar.

Let me know what you think in the comments.

The post Laravel Transformable – An Eloquent Model Trait for Consumable Models first appeared on Adam Anderly.

At my company, Saint Systems, we have a non-profit client that uses Office 365 and Microsoft Dynamics CRM plus WordPress for their front-end website. Initially we searched for an existing plugin, add-on or integration between Gravity Forms and Dynamics CRM to no avail. So, we decided to build one and scratch our own itch.

The result is the Gravity Forms Dynamics CRM Add-On – a WordPress plugin that allows you to quickly integrate Gravity Forms with Microsoft Dynamics CRM. Easily create leads or contacts in Microsoft Dynamics CRM when a form is submitted.

Key Features

• Quickly and easily integrate with Dynamics CRM when a form is submitted.
• Create a lead in Dynamics CRM when a form is submitted.
• Create a contact in Dynamics CRM when a form is submitted.
• Update a lead in Dynamics CRM when a form is submitted.
• Update a contact in Dynamics CRM when a form is submitted.
• Choose a Dynamics CRM user as the lead or contact owner.
• Avoid duplicates by checking for existing leads and contacts by email address.
• Use Gravity Forms built-in Conditional Logic to only integrate with Dynamics CRM when you want to!

We’re planning on an October 2015 release and are anxious to get it in your hands. The plugin is now available for purchase.

Find out more about it on the Gravity Forms Dynamics CRM Add-On product page.

The post Gravity Forms + Microsoft Dynamics CRM first appeared on Adam Anderly.