A QUESTION FOR SALES AGILITY ...

I recently picked up a book by John Mertic titled “The Definitive Guide to SugarCRM”.
(The reason I am posting here is that SuiteCRM is still largely based off the original Sugar PHP code, so much of the book would still apply).
In his book, John describes the underlying structure of the SugarCRM software … its MVC (Model View Controller) architecture.
The apparent benefits to using MVC is that it separates the different application layers and speeds up development of the software by using standardized templates and definition files. Therefore, it becomes relatively easy to add functionality to the software.
Is it the intention of Sales Agility to continue using this MVC framework or are you guys slowly migrating to something else?
The context of my question is related to the ongoing problems that many users still have when trying to create custom modules and relating them to existing SuiteCRM modules/tables. Custom themes are another area where there have been issues.
It would seem to me that if the underlying MVC “engine” was totally bug-free, then there should not be any bugs in anything built on top of it.

Hi there paullm!

The MVC model was at the heart of SugarCRM, and it still is at the heart of SuiteCRM, and will be for the foreseeable future.

This doesn’t mean that every bit of SugarCRM used that model correctly, and there are many places in the code where the plain PHP-that-does-stuff-and-dumps-it-on-the-screen “model” is used. We’ve fixed some of these, but nowhere near all.

Note two things:

1- the software architecture model is really not that related to buggyness. You can make crappy code based on a good model, or great code with no conscience of models. If I can use an analogy: it’s like saying that democracy guarantees prosperity. It does, except in all the cases where it doesn’t :slight_smile: It’s more correct to say that it helps, or that it prevents some problems, but not all. The same goes for the MVC model: it’s nice, it helps, but it does not ensure anything about code quality. It’s merely a good basis for it.

2- the MVC model is about programmers doing programming work, which includes debugging, testing, and a lot that goes beyond the basic model used. It is not about a tool called Studio which does a (tiny) bit of that programming work for you. So any difficulties with custom modules done from Studio really has little to do with MVC. The tool is limited. If you have a developer who knows how to properly use the MVC model and write a custom module from the ground up, there’s nothing to stop you from creating great code. I’m pretty sure it won’t be bug-free, though…

3- Custom themes don’t have much to do with this.

I hope this clarifies some points, I don’t know if I’ve explained well enough…

Cheers!

Hi Pedro and thanks for the clarification!

I guess I had the feeling that with the previous debacle over the single/limited Suite P theme in the original version 7.10, it was some kind of a “hard-coded” issue and not using MVC.

Also, in the older versions of SuiteCRM, you were able to get into the PHP code and quickly change the number of columns in Detail and Edit views from two to three or four, for a more compact layout. That capability also disappeared in 7.10.

About the columns: it’s perfectly possible, but now that it uses bootstrap, it has to be done the bootstrap way.

I made an example here:

https://pgorod.github.io/Admin-menu/

This is actually a pretty neat way to describe columns, it’s very clean and responsive to screen sizes. But it is a bit complex to learn, I guess, and I got quite confused while doing it, I just had to go with trial-and-error.