I'm wanting to port a simple laravel application to OctoberCMS but I am confused about the correct way to structure things. Firstly can I require composer packages that are not pre-installed with October and secondly what is the right structure for placing controllers in OctoberCMS that respond to form requests eg: GET requests and then having those controllers pass data to views ?

Basically my application takes a form input, then uses some business logic to handle the input, the controllers handle the get requests via routes depending on input and then the controllers make API requests using Guzzle and then refactors JSON data into arrays which are passed to views that a paginated using an external pagination library.

However I am having some difficulty understanding how that can translate to the October way of doing things.

Can anyone help me understand how this is Laravel would translate to OctoberCMS, do I create plugins, or components ? Or is there a best practice for this kind of thing ?

Yes, you can use (i.e., require and actually use) composer packages in October just like in plain Laravel.

I'm not an expert on October (yet) but am coming from an (H)MVC background myself, too (FuelPHP, Slim, F3). What I've come up with is this:

• CMS Pages in OctoberCMS are like controllers in a standard MVC framework
• If you want data processing inside these pages, either put them in the markup of the CMS page (inside the php function function onStart() (see the docs)
• If you want more data processing than just a tiny little bit, write a component. You can think of it that way that it is the H in HMVC. Every component can be a dispatched call to the components logic. Whatever that component does with the request data is up to the component. If the component produces output or not: only the component knows

Components are a subset of plugins. A plugin can be understood as October's wording for a composer package. A component would somehow be a dispatched called to a specific hierarchical controller call. Or a model - well, ViewModel would be a better wording.

For you this translates to (using the Laravel - OctoberCMS dictionary I created for myself): Create a plugin which has all the data handling logic. Inside this, create models (but not October-styled models so no-database-interaction-models, just models that do the business logic). Also create one or more components that you plop into a CMS page. This component would then basically be the body of your Laravel-controller function i.e., gather the form request data, pass it to the model that performs the API requests and returns JSON data. As a last step the components onRun method would render the content so calling the view with the JSON data passed to it. Pagination can here be done inside the aforementioned API-request-model with the current page being passed from the component to the model and paginated data returned from the model.

Hope this helped. And also hope it's a correct way of translating pure-Laravel to October-Laravel.

Last updated 9 years ago

Thanks for the detailed reply.

Coming from pure Laravel, it seems like there's a bit of a learning curve to fully appreciate how everything is structured with October.

At the moment I am using the experiment and break, then further experiment method of coming to grips with it all.

Like with everything new there's a learning curve. For October I think the curve is rather low in the beginning until you read through all the docs and connected the dots but then it picks up speed and it's quite a steep curve. And then you will be like "Wow, what a great thing October is. All these fancy services and traits they're providing us with. Why hasn't there been anything out there providing it in such a way before?" And that's not just limited to the PHP/Laravel part, but seriously, these guys have a very sophisticated javascript framework baked right into October. That's just awesome!