Hello,
I’m an experienced Laravel and WP dev but I always used them separately.
I’m going to start a new project with radicle 1.4.0, this is my first time, and even after reading all the docs I’m still a bit confused.
I have to create kind of ecommerce admin dashboard.
I will create my own code plus I will make use of some standard wp plugins.
Before getting started with Radicle I would have acted in this way:
create my plugin inside /wp-content/plugins/my-plugin containing all the business logic. my plugin made use of composer and mozart to prefix dependencies.
create a theme to display the data
I stick to MVC so Models and Controllers sit into plugin while View sit inside the theme.
My plugin always contains an src/ folder with PSR-4 scaffolding for all the needed stuff.
Now I want to use Radicle for the first time, my questions are the following:
should I consider the resources folder the same as my theme folder?
should I work directly inside the resources root or not? Should I create a subdir with my theme name or is unecessary?
where should I put my business logic? Should I create a plugin inside content/plugins as I’m already used to or not? I though to put my code inside app/Http/Controllers.
should I consider the resources folder the same as my theme folder?
Yes. In the resources folder, you can find all your view files, the same template hierarchy as any other WordPress theme, but view files are blade.
should I work directly inside the resources root or not? Should I create a subdir with my theme name or is unnecessary?
Yes, you should work directly inside the resources root. You don’t need to create a subdir for your theme name or other things. Basically, Radicle is your theme.
where should I put my business logic? Should I create a plugin inside content/plugins as I’m already used to or not? I though to put my code inside app/Http/Controllers.
Your business logic should be placed in app/View/Composers. You should read more about Composers here Composers | Sage Docs | Roots .
View composers are callbacks or class methods that are called when a view is rendered. If you have data that you want to be bound to a view each time that view is rendered, a view composer can help you organize that logic into a single location. View composers may prove particularly useful if the same view is returned by multiple routes or controllers within your application and always needs a particular piece of data.
I understand the possible use cases but I don’t think ViewComposers replaces my Controllers and Models.
I use MVC in the following way:
View just displays content
Controllers are “thin” and doesn’t contain any business logic, they just run some sanity checks then they pass data to Models
Models are a set of classes that rapresent Business Logic, Entitites, Validators and so on.
Are Composers in the context of Radicle/Sage intended as a drop-in replacement for Controllers?
As far as “where should I put my code” goes — that’s a question that you have to answer yourself. As an experienced Laravel and WP dev, can you not make these decisions after looking at the project structure?
Kind of? It has all the views and assets.
Why would you not work within the resources directory? Radicle isn’t a framework — you can do work anywhere you’d like.
Do you want to create a subdirectory? Go for it!
Do you want to create a plugin? Do it!
Do you want to put code in app/? You can do that, too
Ok, I found the first paragraph on the page a bit misleading then
Composers, also sometimes called View Composers, are essentially identical to the Laravel system of the same name. They allow you to pass data to views (blade templates), scoping that data to that view (and any views it subsequently includes). If you’re familiar with Sage 9’s data filters, or the Controller package often used with Sage 9, then Composers are a similar concept, but much more powerful: Instead of only allowing data binding to top-level WordPress templates, Composers allow you target any view.
Thanks for your reply.
I was worried about “breaking stuff” and “wasting time” by putting files where not expected.
Now I understood that despite the scaffold I can do whatever it makes sense to me, so problem solved
It’s technically not wrong – it’s just that Acorn abstracts the need to manually register View Composers alongside having its own way of attaching data to specific views to make it a bit more dynamic and sensible for use with the WordPress template hierarchy.
