Please separate PHP code and HTML

[SBA18]

Hi,

Please separate the php code and html. Why in 2018 dolibarr not move to a MVC and stick to old fashion. Why it's so hard to create a simple theme. Because I see the default themes uses PHP code inside CSS file. WHAT!!!!!!!!!!!!!.

Please DEV guys I know it take time to shift all the architecture, but MVC is not new and all other ERP opensource are all moved to MVC. Maybe version 7 will not be but change all in Version 8.

Thanks.

[laudeco]

Hello @acericonia,

First of all I want to thank you for the time I lost reading you ticket.

1. This ticket is not very constructive ...
2. It's not a bug or a question ...
3. Up to you to come with a solution, for css by exemple ...

L.

[dolibarr95]

Hi ! https://www.dolibarr.fr/forum/11-suggestionsnouvelles-fonctionnalites/61037-addstylesheet-addscript-for-header

[SBA18]

Hi @laudeco

First you don't have to read my ticket if this is not interesting you. Second I'm sorry for the time you lose by reading this ticket. This was a request for the Dolibarr devs.

My salutation.

[eldy]

There is a misunderstanding of what is a MVC architecture. MVC does not means the controler and the view are in different files. It means they are separated.

Code of controler is in the part just after the / Action comment and the view is after the / View

So controler and view are always on hand when developing and

Currently this MVC architecture has prooved it has a really better efficiency maintenance than very old MVC way of working that make the controler code and the view into separated files.

[borisduin]

Eldy, sorry but i think you are giving a personal opinion. Separate controllers and view is better for rehusability and low coupling. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

[dolibarr95]

Hi And there are a lot of .tpl files in Dolibarr isn't what you want ?

[borisduin]

Quantity is not the same as quality

[dolibarr95]

So what kind of correction do you suggest for those tpl files?

[laudeco]

First of all @acericonia sorry for my first quick response I was focusing on the CSS and not on the MVC.

But globally I totally agree with you guys! A good MVC would be much more easier to manage. I already thought to fork and start with a solution based on Symfony. But to be honest this project does a lot and it's nearly impossible to refactor something without touching to the architecture.

What do you propose ? At the moment I'm fixing bugs and I don't have time for a code freeze ...

[borisduin]

I agree with you @laudeco. Symfony last version is very powerful and clean, but a framework should be selected via consensus or majority

[hregis]

@acericonia @laudeco @dolibarr95 @eldy @borisduin Migrating to a different development mode is a titan job! What is a Framework? A set of function easy to use and develop! Modify / complete Dolibarr to add the missing features! Consider Dolibarr as a Framework!

[borisduin]

@hregis , I disagree with you. Dolibarr is a monolitic app with thousands of files with spaguettis and repetitive code, not a Framework.

[hregis]

@borisduin yes this is an application that started in 2003! It's up to us to do better with this Framework! ;-)

[borisduin]

Ok. But It's time to think about remodernizing the app.

[SBA18]

@hregis nothing is impossible. I know is a titan work, but it must be start before and make step by step and module by module. What ever framework (Symfony, zend, or Laravel etc...) will be welcome. I don't ask they now, but for futures releases. Now there is not event a sign that shows they are working on it.

@laudeco You welcome, now you understand what i'm talking about. for just changing menus or table positions is a nightmare now on dolibarr. you have to change this and that and after you update for new version you lose all changes. I would like to have in the theme folder all the front-end files and update don't overwrite it. maybe I'm dreaming :-)

[laudeco]

@acericonia yup for me we should begin with at least one module but I don't know how it's possible to "share" the session between the legacy and the framework ...

[SBA18]

@laudeco sharing will be hard as you said. According dolibarr roadmap in view weeks version 7 will be out. They just need to prepare the next big release like january 2019 and put all resources for switching framework. I'm not a expert or high profile developer, but I think they can do it. Maybe I'm wrong.

[SBA18]

Note : version is out right now ...

[absnc]

• There seems, on the separation subject, that some work had been achieved before.

I've been trying to get my hands on this part, but couldn't get any significant explanation on why it this piece of code had been rolled back, yet :

https://github.com/Dolibarr/dolibarr/commit/e1c009fce4dcc338cdee4dde4d2b6f96bd98d9bc#diff-d40b7911852f493a88868b349acf3fbe

any further explanations or insights ? were there some limitations on the JS part, binding ?

• Also, there are other few things that could probably benefit some rearrangements. For say, I've recently found, if I wasn't wrong, an example of section mismatch between View and Actions components :

https://github.com/Dolibarr/dolibarr/blob/60fe1fa503eb64a3e0f02b9d50ce9ec270ecd767/htdocs/expedition/card.php#L896

[ParisLiakos]

Related issue #6198 and pull request #6320

[ruistrecht-alt]

This issue has been on my mind for quite some time, although I understand that dolibarr, as it is, is totally independent from MVC frameworks and has such can capitalize in certain disadvantages of the popular PHP frameworks (https://code.tutsplus.com/tutorials/should-you-use-a-php-framework-five-pros-and-cons--cms-28905) like slow execution and bulky code.

But on a personal and professional level I agree with @acericonia and many of the commenters here. MVC implementation has always been my first rule to follow when starting to develop a new web app. I think that code readability and maintainability absolutely has priority over code quantity and execution speeds, this because code optimization and integrating new features will be much easier on the long run.

At the moment Dolibarr is a huge mess of a highly working code, and if it weren't for the search in all files feature of code editors I wouldn't know where to start developing. I have some experience in developing Laravel apps, and just thinking of migrating dolibarr to Laravel gives me the shivers.

[cmmata]

According to Wikipedia, Symfony started in 2005 (only two years later than Dolibarr) and it's always changing and modernizing parts of the framework and libraries. I know it's a huge work to refactor Dolibarr and use a third party or an own framework, but I think it would help newcomers a lot.

At the moment I'm using it for my personal projects, and I thought to develop some new functionalities or to create a new theme, but then looking at the code I felt overwhelmed and forgot that idea.

[absnc]

Variables that are being initialized from outside a tpl file, thus obfuscating their behaviour inside a given tpl file, shouldn't be a concern related to MVC(2) pattern at all (#6320).

Graphically reusable components, would logically be called and initialized with clearly defined parameters in any case; as opposed to apply simple code ellipsing in the current situation, right ?

As far as I understand, tpl files were introduced so to give external developers, a way to override the default behaviour of some key system components/widgets (product lines, dialog boxes, etc), on the same principle as hooks, that give developers a way to add custom functionalities.

The problem, is that anyone could write tpl, in a 'unconventional' manner (interlacing display and logics, in a way that also gave PHP the bad reputation we all know). That, could potentially lead to problems, when some developments/enhancements need to deeply rely on one each other. (let say, my installation already uses X modules that override default tpl's with their own. What happens in case I also need to customize my own same tpl's ? couldn't some overloadable OOP graphical object be handy in that case ? ).

One way to address those concerns, would consist of defining consensually, how shared graphical components need to be instanciated (framework?). As well as establising a common/central real-time (shared..) datastructure, globally defining the way these objects mutate under certain conditions. There are few templating engines and frameworks (could also be it a custom one), that actually address those questions; picking an existing one would also allow the avoidance of redefining, in details, all possible scenarios...

[altairis-tof]

i agree with @hregis : it would be much efficient to improve dolibarr model than to spend years to rewrite it on a mvc framework. From my point of view, the first thing to do would be to refactor duplicate code in all card.php (in the "action" part and also in the "view" part). Other projects would be to improve menu management, theme management, and better use of ajax in terms of reusability and extensibility. If you guys have time and real desire to help, this is a good start, i think. Then, current devs could continue to focus on functionalities without being harrassed by a migration to a new framework. My 2 cents.

[absnc]

@altatof Dolibarr's model ? datamodel ? not sure it's part of the current issue's concern.

Talking about presentation, and card.php in particular. Sure, let's say one is willing to refactor a few common actions, like 'validate', 'close', etc, as well as pure 'view' components, 'totals' for example. Is there an agreement on the where those common components would be stored (except from the class and tpl folders) ?

Regarding the question on ajax, it's already showing some limitations(extensibility ?), once used on more robust/complex projects. But it sure get's the job done for now, and question is probably out of scope.

On the other hand, I can't see in which scenario; working on product completeness as well as bringing few agreed (code) design conventions (be it on paper, to start with) being mutually exclusive.

my getrate($devise_code) * $price_min ; )

[altairis-tof]

@absnc sorry we seem to live on different planets, i don't understand what you suggest as much as you seem to not understand my point. I was just giving concrete actions you can do to help improve dolibarr code without rewriting everything. But if you prefer to write your own ERP, good luck ;-) And remember just one thing : always focus on users needs.

[absnc]

@altatof Sure, I think I might understand pretty accurately. I was just assuming that you realized we were also users, in a sense, as well...

Then, let's say we want to achieve the few enhancements you talked about: refactoring cards. Could you maybe be a little more specific in terms of where to put newly simply refactored pieces of code ? Not sure whether it is a matter of a few hour or a few days answer though.

[jameszhang023]

@ruistrecht-alt i agree with you

[citadev]

@laudeco @acericonia It's possible to share session between Symfony and legacy code. One way to do a progressive migration with Symfony is to "wrap" Symfony around the legacy code.

For example : new routes (for migrated modules) will be directly managed by Symfony, and a fallback route will be triggered for routes still managed by legacy code. Symfony has to start the php session, which then will be available to the legacy code (you can share auth between Symfony and legacy using event listener and various helpers). It's not as simple as it sounds, the fallback route and the session management could be a pain to set up depending on the complexity and architecture of the legacy code, not to forget sharing the ui layout between new and legacy, merging multiple template from various engine, and other topics...

If money and time weren't a problem I would do it just for fun :)

Another way to look at it : migrated modules are only available as rest api (headless ERP, anyone ?), and front integration is done with a front lib/framework like vuejs. There is still the question of shared auth but no headache with wrapping symfony around the legacy code. Never done this, but I might start next month on another project.

Whichever the way, progressive migration is a lean way to do things, in fact it's not migration at all it's continuous evolution so to speak. It aims at creating a stable frame on which coexist new and legacy code, so there is no full rewrite and throw away of working code.

Just my 2 cents.

[borisduin]

Hi @citadev. Checking symfony 4 project, i found this.

https://symfony.com/doc/current/session/php_bridge.html https://symfony.com/doc/current/components/http_foundation/session_php_bridge.html

I want to help in the migration to Symfony

[absnc]

Also, pure php, being more efficient performance wise, than going the template route, actually compensates the fact that we already have a few mandatory page reloads atm.

Then, maybe we should start looking towards alternate approaches that might address a few of those quirks altogether.