Hello,
I’m moving an application I was developing on plain Laravel to OctoberCMS 3.1 (just bought a license)
It doesn’t have that much code: I had 5 Models that represent each DB table, 5 Repository that handle all the logic and processing, 5 Controllers responding to requests that deliver data processed in the Repository to the front end. This was the best practice I followed that kept all the code clean and separated.
However with October I would need to create a plugin. The Model “function” remains basically the same, the Controller is now for the backend interface so Component becomes my new “Controller” (that delivers data to the front end or API). So I’m missing where I should put all of the logic I used to put in Repositories. That is all the processing, checks etc that should not be (or that I would keep separate) in a Model or a Component.
I think what confuses me is that Laravel Controllers used to respond directly to browser requests and in OctoberCMS that does not exist anymore since it’s the CMS that handles the requests based on the URL.
Any suggestions or best practice (if there’s any)?
Thanks!
Hi @sandros87
I will step through the conversion from Laravel to October, although it is clear you are already at the plugin stage, we will repeat the steps for posterity.
To start, pick a namespace for your company and then a plugin name. A generic plugin can be called App; an example company would be Acme.
php artisan create:plugin Acme.App
All files will then go in plugins/acme/app, and the following paths are relative to this:
5 Models that represent each DB table
place these files in models/ directory, and the database migrations go in the updates/ directory along with an updates.yaml file used to execute them.
5 Repository that handle all the logic and processing,
place in the classes/ directory
Controllers responding to requests that deliver data processed in the Repository to the front end.
In October CMS controllers (found in the controllers/) are used explicitly for backend pages. So for traditional Laravel controllers, we call them “handlers”, and they go into the /handlers directory. There is also a routes.php file to register the routes.
The sitemap plugin has an example of this: GitHub - rainlab/sitemap-plugin: Generator for sitemap.xml files in OctoberCMS
I hope this helps!
Thanks, looks pretty easy. Maybe this way of explaining it should be added in the plugin section of the documentation? I didn’t see handlers and classes in the plugin section.
No worries. It’s there deeper in the documentation:
It’s more common to use CMS components as frontend controllers:
You can build an API with theme templates. Here’s the documentation on that:
Sorry, you suggested classes and handlers directories names as arbitrary names or is it “forced” like the models or components directories? That’s what I meant.
The only forced one should be controllers since routing here is automated. For everything else, you should be free to use any package structure.