### **Where To Put "Stuff"** ### When developing applications with Laravel, you may sometimes wonder where to put "stuff". For example, where should you put "helper" functions? Where should you put event listeners? Where should you put view composers? It may be surprising for you to know that the answer is: "wherever you want!" Laravel does not have many conventions regarding where things belong on the file system. However, as this answer is not often satisfactory, we'll explore some possible locations for such things before moving on. #### **Helper Functions** #### Laravel ships with a file full of helpers functions (``support/helpers.php``). You may wish to create a similar file containing helper functions relevant to your own application and conding style. A great place to include these functions are the "start" files. Within your ``start/global.php`` file, which is included on every request to the application, you may simply require your own ``helpers.php`` file: ~~~ <!-- lang:php --> // Within app/start/global.php require_once __DIR__.'/../helpers.php'; ~~~ #### **Event Listeners** #### Since event listeners obviously do not belongs in the routes.php file, and can begin to clutter the "start" files, we need another location to place this code. A great option is a service provider. As we've learned, service providers are not strictly for registering bindings in the IoC container. They can be used to do all sorts of work. By grouping related event registrations inside of a service provider, the code stays neatly tucked away behind the scenes of your main application code. View composers, which are a type of event, may also be neatly grouped within service providers. For example, a service provider that registers events might look something like this: ~~~ <!-- lang:php --> <?php namespace QuickBill\Providers; use Illuminate\Support\ServiceProvider; class BillingEventsProvider extends ServiceProvider{ public function boot() { Event::listen('billing.failed', function($bill) { // Handle failed billing event... }); } } ~~~ After creating the provider, we would simply add it our providers array within the ``app/config/app.php`` configuration file. > ### **Wear The Boot** ### > > Remember, in the example above, we are using the boot method for a reason. The register method in a service provider is only intended for binding classes into container. > #### **Error Handlers** #### If your application has many customer error handlers, they may start to take over your "start" files. Again, like event handlers, these are best moved into a service provider. The service provider might be named something like QuickBillErrorProvider. Within the boot method of this provider you may register all of your custom error handlers. Again, keeps boilerplate code out of the main files of your application. An error handler provider would look something like this: ~~~ <!-- lang:php --> <?php namespace QuickBill\Providers; use App, Illuminate\Support\ServiceProvider; class QuickBillErrorProvider extends ServiceProvider { public function register() { // } public function boot() { App::error(function(BillingFailedException $e) { // Handle failed billing exceptions ... }); } } ~~~ > ### **The Small Solution** ### > > Of course, if you only have one or two simple error handlers, keeping them in the "start" files is a reasonable and quick solution. > #### **The Rest** #### In general, classes may be neatly organized using a PSR-0 structure within a directory of your application. Imperative code such as event listeners, error handlers, and other "registeration" type operations may be placed inside of a service provider. With what we have learned so far, you should be able to make an educated decision on where to place a piece of code. But, don't be hesitate to experiment. The beauty of Laravel is that you can make conventions that work best for you. Discover a structure that works best for your applications, and make sure to share your insights with others! For example, as you probably noticed above, you might create a ``Providers`` namespace for all of your application's custom service providers, creating a directory structure like so: ~~~ <!-- lang:php --> // app // QuickBill // Billing // Extensions //Pagination -> Environment.php // Providers -> EventPusherServiceProvider.php // Repositories User.php Payment.php ~~~ Notice that in the example we have a ``Providers`` and an ``Extensions`` namespace. All of your application's service providers could be stored in the ``Providers`` directory in namespace, and the ``Extensions`` namespace is a convenient place to store extensions made to core framework classes.