So about a week or so ago I found myself started a few projects, some for clients and some personal. While I doing this I noticed that I was copying and pasting a lot of basic classes and configurations that I use in almost everyone of my projects, so I decided to create myself a toolkit to use with my projects. My choice was an annoying composer configuration connecting to private repositories, or just making it a public repository with a package on packagist, so naturally I went with the second option. You can find the package here, and the repository here.
As I stated above, the idea behind this was to provide myself with a simple toolkit for us in my projects, to save myself duplicating code and having the modify multiple files if I fix a bug or make improvements. That being said, it’s available for others to use should they wish for a basic toolkit, or would like a basis to build their own. With that in mind, I’ve decided to write this article with some further information regarding it.
Installation is simple, and can be installed using composer.
Then you just need to modify app/config/app.php and my ServiceProvider to the list. The position isn’t entirely important, providing that it appears after the default Laravel routing one.
The configuration is simple, and can be published for modification using the Laravel public package config command.
The configuration options are relatively straight forward and are explained in the comments surrounding them.
The toolkit itself is rather simple right now, but it’s something I plan to add components to, and improve upon as I go.
As those of you that follow my blog will be aware, I’m quite militant regarding the route definitions of Laravel applications, which is why I added this method. I’m a huge fan of explicitly defining each route, but I do admit that more often than not, the routes file can become very, very long. This method was created to simplify the process of splitting these routes out.
The method takes three arguments, $prefix being the value that will be passed to the prefix attribute of the group, $file being the name of the file, and $attributes being an entirely optional argument that works the same way as it would on Route::group().
NOTE Adding a prefix to $attributes will have no affect and will be overwritten with the value of $prefix.
Now imagine I have the following file in app/routes/user.php.
My app/routes.php file would look like this.
The BaseRepository is a simple abstract class that I created to house the generic functionality for my repositories, if you’re unfamiliar with the repository pattern I recommend heading over to Laracasts and checking out the videos there on the subject.
Below is the basic structure of the BaseRepository, it’s named quite sensibly so I’m not going to go into every single method, but instead focus on those that may not make much sense.
This method is simple and just allows you to set the model for use with the repository. This is actually called internally in the construct, and is a simple setter.
Again this is a simple setter that is designed to work my BaseValidator (covered below).
This is basically a wrapper for setModel(), and only exists to separate the contextual usage of a repository. Say for example you have a User, which belongs to Company, and therefore can only see Posts that belong to the Company. You would use this method to set the context so that all actions taken are performed on the subset of Posts that belong to Company.
This is basically the getter for the model, including context.
BaseRepository::lists($value, $key = null, $select = false, $id = 0)
This works the same as Model::lists() or Collection::lists() except that it has two extra parameters. If $select is set to true, the array returned will have ‘Please Select One’ prepended to the array. If $id is set to any integer above 0, the row with the corresponding id will be excluded from the list. An example of these two parameters being used would be if you’re deleting a Category and during the process, has an extra option to reassign Posts to another category, obviously you wouldn’t want the Posts to be reassigned to the category you’re deleting.
This works the same way as get, and simply allows you to specific a single where clause.
Truncates the table.
The BaseValidator is designed to work alongside the BaseRepository and provides a nice simple way to separate out the rules for various different processes. There are two methods that can be called for this.
To use the BaseValidator, simply extend it and defined the $rules property.
This method will validate the array passed against the create section of the $rules array.
BaseValidator::validForUpdate(array $data, array $rules = )
This method will validate the array passed against the update section of the $rules array, merged with the optional array passed.
The ValidationException is one thrown when a validation does not pass, this is caught automatically within the package and a generic action is taken. The generic action is a simple one.
If you wish to do something different, set ‘catch_validation’ in the config to false.
Recently I’ve encountered a few cases where I need validation rules that do not match that of create or update, so I was creating a slight work around. That being said, there’s no reason you couldn’t add more to the rules array and create your own validForMyAction() method.
That about covered the package as it is, I hope some of you find this useful, for whatever reasons. Enjoy.