30,997
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
m
→Design patterns and Object programming
No edit summary Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 552: | Line 552: | ||
-> For Dolibarr development, it is recommended to use the connection mode '''Active Record''', which offers the advantages of a model close to the business without having the complexity, without obfuscating technical architecture. It is by this way that the development, understanding of code and technical maintenance and / or business behaviour seems the more productive (this is however an ongoing debate between the purists and the pragmatists, debate in which nobody can really be right, because it depends on the objectives). | -> For Dolibarr development, it is recommended to use the connection mode '''Active Record''', which offers the advantages of a model close to the business without having the complexity, without obfuscating technical architecture. It is by this way that the development, understanding of code and technical maintenance and / or business behaviour seems the more productive (this is however an ongoing debate between the purists and the pragmatists, debate in which nobody can really be right, because it depends on the objectives). | ||
[[Category:Development]] | [[Category:Development]] | ||
== Design Pattern for Graphic interfaces == | |||
There are several design patterns for user interfaces (MVC, MVP, MVVM). | |||
Many confuse this design pattern with that of using a template framework. It's unrelated. A template framework (see previous point) is only linked to the "V" part of these models. | |||
-> Dolibarr uses the '''MVC''' Design Pattern. Part M is materialized by a DAO class containing the CRUD (Create-Read-Update-Delete) methods for accessing the table. | |||
Many frameworks have chosen to put the C code part (Controller) and the V code part (view) in files, or even separate directories. The maintenance seems easier on paper, in practice, you have to juggle constantly between n files, the C being strongly linked to the V. Also in Dolibarr, the separation is made by a simple comment section. The part of code C (Controller) is therefore the code that is the tag | |||
<pre> | |||
/ * | |||
* Actions | |||
* / | |||
</pre> | |||
It is followed by the part of code V (Vue), well separated from the C by the tag | |||
<pre> | |||
/ * | |||
* View | |||
* / | |||
</pre> | |||
This mode of separation has had a neutral effect on new developments but has made it possible to reduce the time required for maintenance and fixing bugs so significantly that it is not envisaged to switch to another type of separation (yes the findings made in real life are not always those expected by school theory). The important thing remains that there is always a separation between C and V, no matter how this separation is materialized, as long as it is (Reminder: Do not confuse the notion of separation of C and V with the notion of separation of the code to feed the data of a View and of the code to format the View, this a principle of separation relating to the Design Pattern of Vue, see next point). | |||
== Design Pattern for Views - Presentation == | |||
There are frameworks that specialize in Vue Design Pattern, the part of formatting the screen seen by the user. | |||
Old versions of Dolibarr used Smarty. This framework is an overlay to an already very powerful screen formatting framework called ... PHP. The benefits being much lower than the disadvantages, it has been abandoned in favor of PHP templates (.tpl.php file) which remain the simplest, the most universal, the most scalable and the most efficient, of the presentation frameworks. Its only flaw is that it cannot guarantee 100% the deviations of a developer who would integrate into the View, a logic unrelated to the presentation (therefore other than code intended for generation, formatting, HTML output , test or loop logic). This point is however controlled by the validation mechanism of the project managers' code. | |||
Here again, it is the experience and the observation of a better productivity performance that has motivated the abandonment of the external Presentation frameworks in favor of the PHP framework. | |||