Dolibarr ERP CRM Wiki - User contributions [en]

Lenguaje y Normas de Desarrollo

2011-06-08T21:13:34Z

Gnovaro: /* Design patterns y programación con objetos */

{{TemplateDocDesarrollo}}

He aquí algunas normas sobre el lenguaje, la sintaxis y las norma de desarrollo en vigor para el proyecto Dolibarr:

= Versiones =

* Dolibarr debe funcionar con:
# Todos los SO (Windows, Linux, MACOS...)
# PHP 4.3 ó + (Debe funcionar sin ningún módulo PHP complementario, exceptuando los módulos de acceso a la base de datos).
# Mysql 3.1 ó +

= Normas Archivos =
* Saltos de linea UNIX
* Espacios y tabs tabs (4 espacios)

= Normas PHP =

* Dolibarr está escrito en PHP y soporta todas las versiones de PHP superiores a la 4.1. Todos los archivos deben de contener la extensión .php

* La llamada a las variables superglobales PHP deben pasar a través de los operadores dedicados $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Los otros operadores ($HTTP_SERVER_GET, ...) están siendo depreciados en el seno de PHP, no deben de ser ya utilizados. Por lo tanto, el código debe funcionar incluso cuando la opción '''register_long_arrays''' esté en off.
Además de que el código debe funcionar cuando la opción de PHP '''register_globals''' esté en off (recomendado por PHP), también lo deberá hacer cuando la opción '''register_globals''' esté en on (por defecto en muchas instalaciones).

* Los smart tags PHP no són utilizados. Las secciones de código deben de empezar por '''<?php'''

* No se permite el uso de la variable '''PHP_SELF'''. Utilice en su lugar $_SERVER["PHP_SELF"]

* Cuando varias variables deben ser inicializadas con el mismo valor, utilize múltiples líneas
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
en lugar de
<source lang="php">
$var1=$var2=$var3=1;
</source>
que es menos eficiente.

* las cadenas deben de ser encuadradas con comillas simples y las variables sacadas de la cadena.
<source lang="php">
print 'Mi texo muestra mi '.$variable.' !';
</source>

* Los comentarios deben seguir la sintaxis de C, es decir, una doble barra invertida para una línea de comentario y el uso de una barra con arterisco para abrir un bloque de varias líneas
<source lang="php">
/* Bloque de comentarios
*
* Fin el bloque
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// comentario de una línea
print $i;
}

</source>

* Los ficheros deben ser guardados en formato Unix (LF) y no en formato Windows (CR/LF). El formato Unix es compatible con los SO Unix, Windows, Mac, mientras que el formato de archivo de texto de Windows es problemático en algunos PHP en Unix.

Las funciones deben devolver >0 en caso de éxito, y un número <0 en caso de error.
A día de hoy, muy pocas funciones cumplen este standard, pero es necesario.

= Normas SQL =

* ¡Los SELECT * están prohibidos! Cada Select deberá especificar la lista completa de los campos para recuperar. Esto permitirá evitar confusiones. Ejemplo:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* En las consultas SQL, entrecomillaremos los campos, pero no los numéricos que contengan cantidades que se almacenen en los campos de tipo double o real. Los entrecomillados en los numéricos de tipo float se almacenan con un valor diferente. Por ejemplo 412.62 dentro del insert se guardara con el valor 412.61999512 en base si el campo es de tipo double(24,8). Y PHP sólo ve 412.61999512. Otras herramientas verán 412.62 dando la impresión de que no hay problemas. Y PHP tiene razón, hay un problema en base. Mediante la eliminación de las comillas en los numéricos, esto irá mejor.

Ejemplo:
<source lang="sql">
Bien:INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mal: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Nota, el problema de los float es general y no sólamete en el acceso a la base de datos, está presente en todos los lenguajes cuando trabajamos sobre números reales, por lo que deberán ser limpiados por la función price2num con el segundo parámetro rellenado con:
'MU', 'MT' ó 'MS' según sea necesario. Consulte el capítulo "Los números reales, importes y cálculos" más abajo.

En la práctica, con la finalidad de set compatible con todas las precisiones de los paises, utilizaremos los siguientes tipos:
- double(24,8) para cualquier importe
- double(6,3) para las tasas de IVA
- real para una cantidad

* Dolibarr debe trabajar incluso con la opción '''strict''' de Mysql activa.
Para activarla, añada la siguiente línea en su archivo config del servidor MySql (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* las funciones NOW ó SYSDATE están prohibidas en las órdenes de SQL. Si se necesita indicar la fecha del momento en un campo, el valor debe provenir de PHP y no del motor de la base de datos. Esto además de ofrecer una mejor portabilidad del código, también permite una gestión correcta de la zona horaria.

= Normas HTML =

* Todos los atributos de las etiquetas HTML deben de estar *en minúscula* y entrecomillados con *doble comilla*.

* Los enlaces href deben de ser absolutos. para las páginas, basarse en la function dol_buildpath(). Para las imágenes basarse en la llamada de la función img_picto.
Por ejemplo:
<source lang="php">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
</source>

* Javascript y la llamada a scripts java en las páginas php está fuera de las normas. Si de todas maneras se incluye código javascript, debe estar condicionado mediante el test "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // El código PHP que genera el javascript va aquí
}
</source>

* Las ventanas emergentes no deben de ser utilizadas, exceptuando los tooltips (y quedan condicionados por el punto anterior).

* Los scripts externos son escritos en Perl si no pueden serlo en php, la utilización de otro lenguaje no está prohibido, pero debe de ser discutido priero en la lista de correo de desarrollo. El lenguaje debe de ser dominado al menos por 2 desarrolladores para asegurar el mantenimiento

= Normas Dolibarr y plantillas de código =

== Plantillas de código ==
Para estandarizar el código y acelerar el desarrollo de nuevos componentes en Dolibarr, en la carpeta '''dev/skeletons''' encontraremos 4 plantillas de código preparadas.

* 1 que sirve de ejemplo de descriptor de módulo: '''myModule.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva clase: '''skeleton_class.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva página: '''skeleton_page.php'''
* 1 que sirve de ejemplo de código para crear una nuevo script a ejecutar en línea de comandos: '''skeleton_script.php'''

Úsenlas como ejemplo.
Tenga en cuenta que estas plantillas también son utilizadas por el generador de código PHP que se describe en el capítulo de Desarrollo de módulos Dolibarr módulo para acelerar su desarrollo.

== Las fechas y la Zona Horaria ==
Dolibarr es una aplicación multi-usuario y multi-ubicación. Por lo tanto, es necesario almacenar las fechas en el formato correcto. Para evitar problemas de conversión, deben aplicarse las siguientes reglas:
* Una fecha en memoria debe de estar en formato Timestamp GMT.
* Una fecha guardada en la base de datos contiene el Timestamp GMT en relación con la fecha que figura en la consulta en hora local del servidor PHP. No se trata de las fechas de actualización de la base de datos (campo '''tms''' en la base de datos).
Por lo tanto, el 1 de enero de 1970, a las 3 en París (TZ=+1) = las 2 en Greenwitch (TZ=0) será almacenado en memora 7200 y será enviado a la base de datos con la cadena '19700101030000' (PHP convierte en hora de su TZ y la base de datos la deconvierte con su TZ que es la misma que la de PHP).

Los métodos select deben traducir los campos fecha al formato de cadenta TZ de la base ('19700101030000') mediante la llamada del método db->jdate para recuperar la información en memoria en formato Timestamp GMT. Y los métodos insert deben deben generar la petición convirtiendo la fecha en memoria conocida en variable, mediante el método db->idate (Ver ejemplos generados por la plantilla).

* Las actualizaciones automáticas de la base de datos (campo '''tms''' en la base) contienen el Timestamp GMT del momento en que se ha realizado la modificación. Los métodos select recuperan directamente este dato en memoria en formato Timestamp GMT.

== Codificación UTF8/ISO ==
Dolibarr guarda la información de la manera siguiente:

* En la base de datos, los datos en UTF8 ó ISO. Esto depende del pagecode de la base de datos, y por lo tanto, de las opciones en la creación de esta base de datos. En todos los casos, el controlador de base de datos Dolibarr (dentro de /lib/database) lee e inserta por conversión desde y hacia UTF8.
* Los datos en memoria se guardan en UTF8 (instancias de objetos PHP).
* las páginas web mostradas en pantalla se encuentran en formato UTF8 (con versiones < 2.5.1, es el antiguo parámetro $character_set del fichero conf.php quien define el formato de salida).

== Los números reales, importes y cálculos ==
Tanto en PHP como en otros lenguajes (Java, por ejemplo), los datos no enteros (float, real, double) no son fialbes.
Pruebe a realizar por ejemplo
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
No obtendrá 0, sino un número muy pequeño en potencia 10 negativo . Si obtiene cero, puede encontrar otros ejemplos que no funcionan.
El problema de los float es general, una variable resultante del cálculo de números reales debe SISTEMATICAMENTE ser limpiada mediante la función price2num con el segundo parámetro rellenado con: 'MU', 'MT' ó 'MS' según el caso (ver doc de la función).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
Si no es un precio que se ajuste a los parámetros de MU, MT, MS debe utilizar la función '''round()'''.

== Creación de tablas ==
No crear una tabla a utilizar, es decir, al '''primer uso''' del módulo.
Si crea un módulo que usa tablas que no se incluyen como estándar en el código de Dolibarr, asegúrese de seguir el tutorial Creación de un módulo que explica cómo incluir las tablas que se crean en la activación del módulo y no en su uso (ver más arriba).

== Logs ==
Añada traces dentro de su código mediante la función dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Carpetas de trabajo ==
Si tiene que crear una carpeta de trabajo, en el código, haga referencia a esta carpeta de la siguiente forma
DOL_DATA_ROOT.'/mimodulo'.
La carpeta puede crearse en desde su código mediante el código siguiente:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/mimodulo';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si necesita una carpeta de datos temporales, esta carpeta deberá ser DOL_DATA_ROOT.'/minmodulo/temp'

= Patrones de Diseño y programación con objetos =
== Patrones de Diseño Creacionales (GoF) ==
Design patterns definidos por el le Gang Of Four (ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns creacionales particulares.
Hay objetos cercanos a los Singleton y creados conforme al 100% en el espíritu, pero no en la sintaxis, a fin de ser compatible con PHP 4 que no es un lenguaje orientado a objetos completo.

== Design patterns Estructurales (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns estructurales particulares.

== Design patterns de Comportamiento (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns de Comportamiento particulares.

== Design patterns enterprise (Martin Fowler) ==

=== Motivos de organización del código ===

[[wikipedia:Martin Fowler|Martin Fowler]] ha identificado 3 métodos de organización de código llamados '''principios''':
* El '''Transaction Script''' (El código es lineal en función de una acción del usuario).
Es el antiguo principio utilizado en los lenguajes de procedimiento.
Inconveniente: Redundancia de código. Necesidad de conocer el modelo físico a desarrollar.
* El '''Domain Model'''
Es un modelo posible desde los lenguajes orientados a objeto. Son procedimentos funcionales (que deben de ser indentificados antes) que sirven de base para las clases objeto.
Inconveniente: Motivo de mantenimiento complejo.
* El '''Table Module'''
Un intermedio entre los 2 anteriores donde se tiene una sola clase por tabla de la base de datos.

-> Como se muestra en el código de la plantilla (ver sección anterior) Dolibarr se basa en el principio de '''Table Module'''.

=== Comunicación lógica de negociado - datos (ORM) ===

Existen 3 tipos de conexiones:
* '''Data Gateway a tablas y filas'''
Es el más simple. Creamos una tabla por clase y cada clase es un puente con la tabla correspondiente, ver una clase por línea tabla. Una instancia de la clase será pues un registro de la tabla. La clase contiene sólo el código de acceso a líneas o columnas de tablas.

Ejemplo: Es el método utilizado al utilizar ciertos Frameworks de ORM como '''iBatis''' (http://ibatis.apache.org/).

* El '''Active Record'''
Idéntico al anterior, pero podemos añadir algunas funciones de negociado en la clase, siempre que estas funciones sean exclusivas de la tabla o la grabación.

Ejemplo: Es el método utilizado por los desarrollos de Dolibarr y por otras muchas aplicaciones en PHP que disponen de su propio propio framework y prácticas de desarrollo.

* El '''Data Mapper'''
Las clases representan las entidades del problema y no los datos. Por lo tanto hay que doblar, triplicar... estas clases con clases de mapeo para acceder a los datos.
Más "purista" en el papel ya que el negociado está más cercano, este método también tiene la desventaja de ser más complejo en la práctica.
Ejemplo: Es el utilizadao si utilizamos el Framework de ORM '''Propel''' (http://propel.phpdb.org/trac/). Lo encontraremos pues en aplicacciones más pesadas basadas en este ORM.

-> Para los desarrollos de Dolibarr, es recomendado utilizar el modo '''Active Record ''' que ofrece las ventajas de un modelo cercano de negociado sin la complejidad y sin dificultar mucho la técnica. Es en este modo mediante el cual el desarrollo, la comprensión del código y el mantenimiento técnico y/o funcional parece ser la más productivo (Sin embargo, se trata de un eterno debate entre los puristas y los pragmáticos, el debate en el que nadie puede realmente estar en lo cierto, porque todo depende de los objetivos a atender).

Language and development rules

2011-06-08T20:51:00Z

Gnovaro: Files Norms

{{TemplateDocDevEn}}

This is some rules on language, syntax and norm we use into Dolibarr project:

= Versions =

* Dolibarr must works on:
# All OS (Windows, Linux, MACOS...)
# PHP 4.3 or + (Must works with no need of complementary PHP module, except module to PHP module to access database).
# Mysql 3.1 or +

= File Norms =
* Line Breaks, use UNIX
* Spaces vs tabs, use TAB (4 spaces)

= PHP Norms =
* Dolibarr is written with PHP and supports all PHP version higher than 4.1. All files must end with extension .php

* Usage of superglobals PHP variables must use dedicated operators $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Other operators ($HTTP_SERVER_GET, ...) are now deprecated inside PHP, so they must no more be used. Like that code will works alos if option '''register_long_arrays''' is to off.
Moreover, the code must works when PHP option '''register_globals''' is off (recommanded by PHP). It must works the same way that when option '''register_globals''' is on (by default on a lot of installations).

* Smart tags PHP are not used. PHP code section must start with '''<?php'''

* Do not use '''PHP_SELF'''. Use instead $_SERVER["PHP_SELF"].

* When several variables must be initialized with same value, you must use several lines
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
instead of
<source lang="php">
$var1=$var2=$var3=1;
</source>
that is slower.

* String must be rounded by simple quote and vairable inside string must be out of the quote.
<source lang="php">
print 'My text show my '.$variable.' !';
</source>

* Comments must use the C syntax, ie a double antislash for a comment on one line and a slash-star to open a bloc for several lines
<source lang="php">
/* Bloc of comment
*
* End of bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// comment on one line
print $i;
}

</source>

* Files must be saved with Unix format (LF) and not Windows (CR/LF). Unif format is compatible on all OS like Unix like, Windows, Mac, but the Windows text file format is no working on some PHP under Unix.

Functions must return a value strictly higher than 0 if successfull and strictly lower than 0 if error.

= SQL rules =

* All SELECT * are forbidden ! Any SELECT must define complete list of fields to get. This avoid confusion. Example:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* Into SQL requests, you must quote fields except fields that contains amounts that must be stored as double or real type. Quotes on numbers may results in saving a different value. For example 412.62 in an insert will be saved with value 412.61999512 into database fi target field has type double(24,8). Only PHP see value 412.61999512. Other tools will see 412.62 giving sensation that there is no problem. But it's PHP that hase the good vision. There is really a wrong value into database. By removing quotes on numbers, no problem occurs.

Example:
<source lang="sql">
Good: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Bad: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Note, problem of float numbers is same problem on all langauges and not only when inserting data into database. It occurs also with any language when you work on "real" numbers, so numbers must be, as soon as they are affected, cleaned with function price2num with second parameter defined to :
'MU', 'MT' or 'MS' depending on usage of number. (see function documentation)

Well, to be compatible with any accurency required by any country on amounts, we will use the following type into database:
- double(24,8) for any amount
- double(6,3) for any vat rate
- real for a quantity

* Dolibarr must works even if Mysql option '''strict''' is active.
To activate it (recommanded when developping on Dolibarr), add the following line into the config file of your Mysql server (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* Functions NOW or SYSDATE are forbidden inside SQL requests. If you must use the current date into a field, value must come from the PHP and not from the database engine. This is to avoid a better portability of code and a correct management of TimeZone.

= HTML norms =
* All attributes of HTML tags must be in lower case and *quoted* with *"*.

* Links href must be absolute and use the function dol_buildpath() to get absolute path from a relative path and img tag must be build using function img_picto().
For example:
<source lang="php">
print '<a href="'.dol_buildpath('/mydir/mypage.php').'">'.img_picto('Texte alt','namepictopng','').'</a>';
</source>

{{ToTranslate}}
* Le javascript et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // Le code php qui génère du javascript est ici
}
</source>

* Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent condtionnées par le point ci-dessus).

* Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs. Le langage devra être maitrisé par au moins 2 développeurs pour en assurer la maintenance.

= Normes Dolibarr et squelettes de code =

== Squelettes de code ==
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire '''dev/skeletons''', 4 squelettes de code tout préparés.

* 1 qui sert d'exemple de descripteur de module: '''myModule.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle classe: '''skeleton_class.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle page: '''skeleton_page.php'''
* 1 qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: '''skeleton_script.php'''

Servez-vous en comme exemple.
Notons que ces squelettes sont aussi utilisés par le générateur de code PHP qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développement.

== Les dates et TimeZone ==
Dolibarr se veut une application mutli-utilisateur et multi-localisation. Il convient donc de stocker les dates dans le bon format. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées:
* Une date en mémoire doit être au format Timestamp GMT.
* Une date stockée en base de données contient le Timestamp GMT en rapport avec la date soumise dans la requête en heure locale du serveur PHP. Cela ne concerne pas les dates mises à jour automatiquement par la base (champ '''tms''' en base).
Ainsi le 1er janvier 1970, 3 heures à Paris (TZ=+1) = 2 heures à Greenwitch (TZ=0) sera stocké en mémoire 7200 et sera soumis à la base de données avec la chaine '19700101030000' (PHP convertit en heure de son TZ et la base déconvertit avec son TZ qui est le même que celui de PHP).

Les méthodes select doivent donc traduire les champs dates lus qui sont au format chaine TZ de la base ('19700101030000') par appel de la méthode db->jdate afin de récupérer une information en mémoire au format Timestamp GMT. Et les méthodes insert doivent lors de la génération de la requête convertir la date mémoire connue en variable, par la méthode db->idate (Voir exemples générés par le squelette).

* Les dates mises à jour automatiquement par la base (champ '''tms''' en base) contiennent le Timestamp GMT au moment où la modification est faite. Les méthodes select récupèrent directement cette donnée en mémoire au format Timestamp GMT.

== L'encodage UTF8/ISO ==
Dolibarr stocke les informations de manière suivante:
* En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
* Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
* Les pages web affichées à l'écran sont au format UTF8 (avec les versions < 2.5.1, c'est le vieux paramètre $character_set du fichier conf.php qui définissait le format de sortie).

== Les nombres réels, montants et calculs ==
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables.
Essayer de faire par exemple
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas.
Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction price2num avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction '''round()'''.

== Création de tables ==
Ne pas créer de table à l'utilisation, c'est-à-dire à la '''première utilisation''' du module.
Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel Créer un module qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).

== Logs ==
Ajouter des traces dans votre code avec la fonction
dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Répertoires de travail ==
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par
DOL_DATA_ROOT.'/monmodule'.
Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être DOL_DATA_ROOT.'/monmodule/temp'

= Design patterns and Object programming =

== Creation design patterns (GoF) ==
Design patterns defined by the Gang Of Four (see wikipédia on [[wikipedia:Design pattern|Design patters]]).
No usage of such patterns is required. We found some objects next to Singletons or Factory but not completely compliant with syntax, this is to be compatible with PHP 4 that is not a pure object language.

== Structure design patterns (GoF) ==
Design patterns defined by the Gang Of Four (see wikipédia on [[wikipedia:Design pattern|Design patters]]).
No usage of such patterns is required.

== Behavior design patterns (GoF) ==
Design patterns defined by the Gang Of Four (see wikipédia on [[wikipedia:Design pattern|Design patters]]).
No usage of such patterns is required.

== Design patterns of enterprise (Martin Fowler) ==

=== Patterns of code organization ===
[[wikipedia:Martin Fowler|Martin Fowler]] has identified 3 way to organize:
* The '''Transaction Script''' (The source code is linear for each user action).
This is the old school used by all procedural languages.
Inconvenient: Redundancy of code. Need to know the physical model of data to develop.
* The '''Domain Model'''
This notion is available with object languages. It is business process (to identify before) that are used for objects classes.
Inconvenient: Model very complex to maintain.
* The '''Table Module'''
This is a mix between 2 previous where we have only one unique class for each table of database.

-> As shown in code skeletons (see previous chapter), Dolibarr use concept of '''Table Module'''.

=== Communication between business logic - data (ORM) ===

{{ToTranslate}}

Il existe 3 modes de liaisons:
* Le '''Table And Row Data Gateway'''
C'est le plus simple. On crée une table par classe et chaque classe est un pont avec la table correspondante, voir une classe par ligne de table. Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables.

Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme '''iBatis''' (http://ibatis.apache.org/).

* Le '''Active Record'''
Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à conditions que ces fonctions soient propres à la table ou à l'enregistrement.

Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développements.

* Le '''Data Mapper'''
Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données.
Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être plus complexe sur le plan pratique.
Exemple: C'est le choix si on utilise le Framework d'ORM '''Propel''' (http://propel.phpdb.org/trac/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.

-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).

Langages et normes

2011-06-08T20:49:02Z

Gnovaro: /* Normes Fichiers */

{{TemplateDocDev}}

Voici les quelques règles sur le langage, la syntaxe et normes de développement en vigueur pour le projet Dolibarr:

= Versions =

* Dolibarr doit fonctionner sur:
# Tous OS (Windows, Linux, MACOS...)
# PHP 4.3 ou + (Doit fonctionner sans aucun module PHP complémentaire hors les modules d'accès base de donnée).
# Mysql 3.1 ou +

= Normes Fichiers =
* Retours à la ligne UNIX
* Les espaces et les onglets (4 spaces)

= Normes PHP =

* Dolibarr est écrit en PHP et supporte toutes versions PHP supérieures à la 4.1. Les fichiers doivent tous comporter l'extension .php

* L'appel aux variables superglobales PHP doit passer par les opérateurs dédiés $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Les autres opérateurs ($HTTP_SERVER_GET, ...) ayant été passés en deprecated au sein de PHP, ne doivent plus être utilisés. Ainsi le code doit fonctionner y compris quand l'option '''register_long_arrays''' est à off.
De plus, le code doit fonctionner quand l'option PHP '''register_globals''' est à off (recommandé par PHP) aussi bien que quand l'option '''register_globals''' à on (par défaut sur de nombreuses installations).

* Les smart tags PHP ne sont pas utilisés. Les sections de code doivent commencer par '''<?php'''

* Pas d'utilisation de la variable '''PHP_SELF'''. Utiliser a la place $_SERVER["PHP_SELF"]

* Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs lignes
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
plutôt que
<source lang="php">
$var1=$var2=$var3=1;
</source>
qui est moins performant.

* Les chaines doivent être encadrées de simple quote et les variables sorties de la chaine.
<source lang="php">
print 'Mon texte affiche ma '.$variable.' !';
</source>

* Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation slash-étoile pour ouvrir un bloc de plusieurs lignes
<source lang="php">
/* Bloc de commentaire
*
* Fin du bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// commentaire sur une ligne
print $i;
}

</source>

* Les fichiers doivent être sauvés en format Unix (LF) et non Windows (CR/LF). Le format Unix étant compatible sur les OS Unix like, Windows, Mac, alors que le format fichier texte Windows pose problème sous certains PHP sous Unix.

Les fonctions doivent retourner une valeure strictement > à 0 en cas de succès, et un nombre < à 0 en cas d'erreur.

= Normes SQL =

* Les SELECT * sont interdits ! Chaque SELECT doit spécifier la liste complète des champs à récupérer. Cela permet d'éviter les confusions. Exemple:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* Dans les requêtes SQL, on quote les champs mais pas les numériques qui contiennent des montants destinés à être stockés dans des champs de type double ou real. Les quotes sur les numériques de type float provoquent parfois un stockage d'une valeur différente. Par exemple 412.62 dans le insert sera en fait stocké avec la valeur 412.61999512 en base si le champ est de type double(24,8). Et seul le PHP voit 412.61999512. Les autres outils verront 412.62 donnant l'impression qu'il n'y a pas de problème. Et c'est le PHP qui a raison, il y a problème en base. En supprimant les quotes sur les numériques, cela va mieux.

Exemple:
<source lang="sql">
Bon: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mauvais: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Remarque, le pb des float est général et pas seulement sur les accès base, il est présent dans tous les languages quand on travaille sur des nombres réels, aussi ils doivent être, dès que affectés, nettoyés par la fonction price2num avec le 2eme paramètre renseigné à:
'MU', 'MT' ou 'MS' selon le besoin.
Voir aussi le chapitre "Les nombres réels, montants et calculs" plus bas.

Dans la pratique, afin d'etre compatible avec toutes les précisions des pays, on utilisera les types suivants:
- double(24,8) pour tout montant
- double(6,3) pour les taux de tva
- real pour une quantité

* Dolibarr doit fonctionner même avec l'option '''strict''' de Mysql active.
Pour l'activer, ajouter la ligne suivante dans le fichier config du serveur Mysql (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* Les fonctions NOW ou SYSDATE sont interdites au sein des ordres SQL. S'il faut saisir la date du moment dans un champ, la valeur doit venir du PHP et non du moteur de base de données. Ceci afin d'avoir une meilleure portabilité du code mais surtout d'avoir une gestion correcte des TimeZone.

= Normes HTML =

* Tous les attributs dans les balises HTML doivent être *en minuscule* et quotés avec des *doubles quote*.

* Les liens href doivent être absolus en se basant sur la fonction dol_buildpath() pour obtenir un chemin absolu depuis un chemin relatif au répertoire htdocs. Pour les tags img, il faut faire appel à la fonction img_picto().
Par example:
<source lang="php">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
</source>

* Le javascript et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // Le code php qui génère du javascript est ici
}
</source>

* Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent conditionnées par le point ci-dessus).

* Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs. Le langage devra être maitrisé par au moins 2 développeurs pour en assurer la maintenance.

= Normes Dolibarr et squelettes de code =

== Squelettes de code ==
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire '''dev/skeletons''', 4 squelettes de code tout préparés.

* 1 qui sert d'exemple de descripteur de module: '''myModule.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle classe: '''skeleton_class.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle page: '''skeleton_page.php'''
* 1 qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: '''skeleton_script.php'''

Servez-vous en comme exemple.
Notons que ces squelettes sont aussi utilisés par le générateur de code PHP qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développement.

== Les dates et TimeZone ==
Dolibarr se veut une application multi-utilisateur et multi-localisation. Il convient donc de stocker les dates dans le bon format. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées:
* Une date en mémoire doit être au format Timestamp GMT.
* Une date stockée en base de données contient le Timestamp issue de la date soumise dans la requête en heure locale du serveur PHP. Cela ne concerne pas les dates mises à jour automatiquement par la base (champ '''tms''' en base).
Ainsi le 1er janvier 1970, 3 heures à Paris (TZ=+1) = 1er janvier 1970, 2 heures à Greenwich (TZ=0) sera stocké en mémoire par 7200 et sera soumis à la base de données avec la chaine '19700101030000' (PHP convertit en heure de son TZ et la base déconvertit avec son TZ qui est le même que celui de PHP).

Les méthodes select doivent donc traduire les champs dates lus qui sont au format chaine TZ de la base ('19700101030000') par appel de la méthode db->jdate afin de récupérer une information en mémoire au format Timestamp GMT. Et les méthodes insert doivent lors de la génération de la requête convertir la date mémoire connue en variable, par la méthode db->idate (Voir exemples générés par le squelette).

* Les dates mises à jour automatiquement par la base (champ '''tms''' en base) contiennent le Timestamp où la modification est faite selon le timezone de la base de donnée. Les méthodes select récupèrent directement cette donnée en mémoire au format Timestamp GMT. Si le timezone de la base de donnée diffère de celui du PHP (un des 2 est mal réglé), il peut donc y avoir des écarts entre date de création et modification.

== L'encodage UTF8/ISO ==
Dolibarr stocke les informations de manière suivante:
* En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
* Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
* Les pages web affichées à l'écran sont au format UTF8 (avec les versions < 2.5.1, c'est le vieux paramètre $character_set du fichier conf.php qui définissait le format de sortie).

== Les nombres réels, montants et calculs ==
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables.
Essayer de faire par exemple
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas.
Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction price2num avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction '''round()'''.

== Création de tables ==
Ne pas créer de table à l'utilisation, c'est-à-dire à la '''première utilisation''' du module.
Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel Créer un module qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).

== Logs ==
Ajouter des traces dans votre code avec la fonction
dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Répertoires de travail ==
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par
DOL_DATA_ROOT.'/monmodule'.
Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être DOL_DATA_ROOT.'/monmodule/temp'

= Design patterns et programmation objet =

== Design patterns de Création (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de création particulier.
On trouve des objets proches des Singletons et Fabriques conforme à 100% dans l'esprit mais pas dans la syntaxe, ceci afin d'etre compatible avec le PHP 4 qui n'est pas un langage objet complet.

== Design patterns de Structure (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de structure particulier.

== Design patterns de Comportement (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de comportement particulier.

== Design patterns d'entreprises (Martin Fowler) ==

=== Mode d'organisation du code ===
[[wikipedia:Martin_Fowler|Martin Fowler]] a identifié 3 méthodes d'organisation du code appelées '''patterns''' ('''motifs'''):
* Le '''Transaction Script''' (Le code est linéraire en fonction d'une action utilisateur).
C'est le motif à l'ancienne utilisé dans les langages procéduraux.
Inconvénient: Redondance du code. Nécessité de connaitre le modèle physique pour développer les parties métiers.
* Le '''Domain Model'''
C'est un concept possible depuis les langages objets. Ce sont les procédures métiers (qui doivent être identifiés avant) qui servent de bases pour les classes objets.
Inconvénient: Motif complexe à maintenir.
* Le '''Table Module'''
Un intermédiaire entre les 2 précédents où l'on a une instance unique de classe par table de la base de données.

-> Comme le montre les squelettes de code (voir point précédent), Dolibarr se base sur le principe du '''Table Module'''.

=== Communication Logique métier - Données (ORM) ===
Il existe 3 modes de liaisons:
* Le '''Table And Row Data Gateway'''
C'est le plus simple. On crée une table par classe et chaque classe est un pont avec la table correspondante, voir une classe par ligne de table. Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables. Le code métier doit alors être ajouté dans d'autres classes. Les liens entre ces classes tables et les classes métiers devant être connues ou déduite de la connaissance du développeur.

Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme '''iBatis''' (http://ibatis.apache.org/).

* Le '''Active Record'''
Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à conditions que ces fonctions soient propres à la table ou à l'enregistrement. C'est le pattern qui offre le meilleur rapport fonctionnalité/complexité.

Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développements.

* Le '''Data Mapper'''
Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données.
Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être plus complexe sur le plan pratique.
Exemple: C'est le choix si on utilise le Framework d'ORM '''Propel''' (http://propel.phpdb.org/trac/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.

-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).

Lenguaje y Normas de Desarrollo

2011-06-08T20:48:32Z

Gnovaro: /* Normas Archivos */

{{TemplateDocDesarrollo}}

He aquí algunas normas sobre el lenguaje, la sintaxis y las norma de desarrollo en vigor para el proyecto Dolibarr:

= Versiones =

* Dolibarr debe funcionar con:
# Todos los SO (Windows, Linux, MACOS...)
# PHP 4.3 ó + (Debe funcionar sin ningún módulo PHP complementario, exceptuando los módulos de acceso a la base de datos).
# Mysql 3.1 ó +

= Normas Archivos =
* Saltos de linea UNIX
* Espacios y tabs tabs (4 espacios)

= Normas PHP =

* Dolibarr está escrito en PHP y soporta todas las versiones de PHP superiores a la 4.1. Todos los archivos deben de contener la extensión .php

* La llamada a las variables superglobales PHP deben pasar a través de los operadores dedicados $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Los otros operadores ($HTTP_SERVER_GET, ...) están siendo depreciados en el seno de PHP, no deben de ser ya utilizados. Por lo tanto, el código debe funcionar incluso cuando la opción '''register_long_arrays''' esté en off.
Además de que el código debe funcionar cuando la opción de PHP '''register_globals''' esté en off (recomendado por PHP), también lo deberá hacer cuando la opción '''register_globals''' esté en on (por defecto en muchas instalaciones).

* Los smart tags PHP no són utilizados. Las secciones de código deben de empezar por '''<?php'''

* No se permite el uso de la variable '''PHP_SELF'''. Utilice en su lugar $_SERVER["PHP_SELF"]

* Cuando varias variables deben ser inicializadas con el mismo valor, utilize múltiples líneas
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
en lugar de
<source lang="php">
$var1=$var2=$var3=1;
</source>
que es menos eficiente.

* las cadenas deben de ser encuadradas con comillas simples y las variables sacadas de la cadena.
<source lang="php">
print 'Mi texo muestra mi '.$variable.' !';
</source>

* Los comentarios deben seguir la sintaxis de C, es decir, una doble barra invertida para una línea de comentario y el uso de una barra con arterisco para abrir un bloque de varias líneas
<source lang="php">
/* Bloque de comentarios
*
* Fin el bloque
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// comentario de una línea
print $i;
}

</source>

* Los ficheros deben ser guardados en formato Unix (LF) y no en formato Windows (CR/LF). El formato Unix es compatible con los SO Unix, Windows, Mac, mientras que el formato de archivo de texto de Windows es problemático en algunos PHP en Unix.

Las funciones deben devolver >0 en caso de éxito, y un número <0 en caso de error.
A día de hoy, muy pocas funciones cumplen este standard, pero es necesario.

= Normas SQL =

* ¡Los SELECT * están prohibidos! Cada Select deberá especificar la lista completa de los campos para recuperar. Esto permitirá evitar confusiones. Ejemplo:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* En las consultas SQL, entrecomillaremos los campos, pero no los numéricos que contengan cantidades que se almacenen en los campos de tipo double o real. Los entrecomillados en los numéricos de tipo float se almacenan con un valor diferente. Por ejemplo 412.62 dentro del insert se guardara con el valor 412.61999512 en base si el campo es de tipo double(24,8). Y PHP sólo ve 412.61999512. Otras herramientas verán 412.62 dando la impresión de que no hay problemas. Y PHP tiene razón, hay un problema en base. Mediante la eliminación de las comillas en los numéricos, esto irá mejor.

Ejemplo:
<source lang="sql">
Bien:INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mal: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Nota, el problema de los float es general y no sólamete en el acceso a la base de datos, está presente en todos los lenguajes cuando trabajamos sobre números reales, por lo que deberán ser limpiados por la función price2num con el segundo parámetro rellenado con:
'MU', 'MT' ó 'MS' según sea necesario. Consulte el capítulo "Los números reales, importes y cálculos" más abajo.

En la práctica, con la finalidad de set compatible con todas las precisiones de los paises, utilizaremos los siguientes tipos:
- double(24,8) para cualquier importe
- double(6,3) para las tasas de IVA
- real para una cantidad

* Dolibarr debe trabajar incluso con la opción '''strict''' de Mysql activa.
Para activarla, añada la siguiente línea en su archivo config del servidor MySql (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* las funciones NOW ó SYSDATE están prohibidas en las órdenes de SQL. Si se necesita indicar la fecha del momento en un campo, el valor debe provenir de PHP y no del motor de la base de datos. Esto además de ofrecer una mejor portabilidad del código, también permite una gestión correcta de la zona horaria.

= Normas HTML =

* Todos los atributos de las etiquetas HTML deben de estar *en minúscula* y entrecomillados con *doble comilla*.

* Los enlaces href deben de ser absolutos. para las páginas, basarse en la function dol_buildpath(). Para las imágenes basarse en la llamada de la función img_picto.
Por ejemplo:
<source lang="php">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
</source>

* Javascript y la llamada a scripts java en las páginas php está fuera de las normas. Si de todas maneras se incluye código javascript, debe estar condicionado mediante el test "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // El código PHP que genera el javascript va aquí
}
</source>

* Las ventanas emergentes no deben de ser utilizadas, exceptuando los tooltips (y quedan condicionados por el punto anterior).

* Los scripts externos son escritos en Perl si no pueden serlo en php, la utilización de otro lenguaje no está prohibido, pero debe de ser discutido priero en la lista de correo de desarrollo. El lenguaje debe de ser dominado al menos por 2 desarrolladores para asegurar el mantenimiento

= Normas Dolibarr y plantillas de código =

== Plantillas de código ==
Para estandarizar el código y acelerar el desarrollo de nuevos componentes en Dolibarr, en la carpeta '''dev/skeletons''' encontraremos 4 plantillas de código preparadas.

* 1 que sirve de ejemplo de descriptor de módulo: '''myModule.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva clase: '''skeleton_class.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva página: '''skeleton_page.php'''
* 1 que sirve de ejemplo de código para crear una nuevo script a ejecutar en línea de comandos: '''skeleton_script.php'''

Úsenlas como ejemplo.
Tenga en cuenta que estas plantillas también son utilizadas por el generador de código PHP que se describe en el capítulo de Desarrollo de módulos Dolibarr módulo para acelerar su desarrollo.

== Las fechas y la Zona Horaria ==
Dolibarr es una aplicación multi-usuario y multi-ubicación. Por lo tanto, es necesario almacenar las fechas en el formato correcto. Para evitar problemas de conversión, deben aplicarse las siguientes reglas:
* Una fecha en memoria debe de estar en formato Timestamp GMT.
* Una fecha guardada en la base de datos contiene el Timestamp GMT en relación con la fecha que figura en la consulta en hora local del servidor PHP. No se trata de las fechas de actualización de la base de datos (campo '''tms''' en la base de datos).
Por lo tanto, el 1 de enero de 1970, a las 3 en París (TZ=+1) = las 2 en Greenwitch (TZ=0) será almacenado en memora 7200 y será enviado a la base de datos con la cadena '19700101030000' (PHP convierte en hora de su TZ y la base de datos la deconvierte con su TZ que es la misma que la de PHP).

Los métodos select deben traducir los campos fecha al formato de cadenta TZ de la base ('19700101030000') mediante la llamada del método db->jdate para recuperar la información en memoria en formato Timestamp GMT. Y los métodos insert deben deben generar la petición convirtiendo la fecha en memoria conocida en variable, mediante el método db->idate (Ver ejemplos generados por la plantilla).

* Las actualizaciones automáticas de la base de datos (campo '''tms''' en la base) contienen el Timestamp GMT del momento en que se ha realizado la modificación. Los métodos select recuperan directamente este dato en memoria en formato Timestamp GMT.

== Codificación UTF8/ISO ==
Dolibarr guarda la información de la manera siguiente:

* En la base de datos, los datos en UTF8 ó ISO. Esto depende del pagecode de la base de datos, y por lo tanto, de las opciones en la creación de esta base de datos. En todos los casos, el controlador de base de datos Dolibarr (dentro de /lib/database) lee e inserta por conversión desde y hacia UTF8.
* Los datos en memoria se guardan en UTF8 (instancias de objetos PHP).
* las páginas web mostradas en pantalla se encuentran en formato UTF8 (con versiones < 2.5.1, es el antiguo parámetro $character_set del fichero conf.php quien define el formato de salida).

== Los números reales, importes y cálculos ==
Tanto en PHP como en otros lenguajes (Java, por ejemplo), los datos no enteros (float, real, double) no son fialbes.
Pruebe a realizar por ejemplo
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
No obtendrá 0, sino un número muy pequeño en potencia 10 negativo . Si obtiene cero, puede encontrar otros ejemplos que no funcionan.
El problema de los float es general, una variable resultante del cálculo de números reales debe SISTEMATICAMENTE ser limpiada mediante la función price2num con el segundo parámetro rellenado con: 'MU', 'MT' ó 'MS' según el caso (ver doc de la función).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
Si no es un precio que se ajuste a los parámetros de MU, MT, MS debe utilizar la función '''round()'''.

== Creación de tablas ==
No crear una tabla a utilizar, es decir, al '''primer uso''' del módulo.
Si crea un módulo que usa tablas que no se incluyen como estándar en el código de Dolibarr, asegúrese de seguir el tutorial Creación de un módulo que explica cómo incluir las tablas que se crean en la activación del módulo y no en su uso (ver más arriba).

== Logs ==
Añada traces dentro de su código mediante la función dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Carpetas de trabajo ==
Si tiene que crear una carpeta de trabajo, en el código, haga referencia a esta carpeta de la siguiente forma
DOL_DATA_ROOT.'/mimodulo'.
La carpeta puede crearse en desde su código mediante el código siguiente:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/mimodulo';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si necesita una carpeta de datos temporales, esta carpeta deberá ser DOL_DATA_ROOT.'/minmodulo/temp'

= Design patterns y programación con objetos =
== Design patterns Creacionales (GoF) ==
Design patterns definidos por el le Gang Of Four (ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns creacionales particulares.
Hay objetos cercanos a los Singleton y creados conforme al 100% en el espíritu, pero no en la sintaxis, a fin de ser compatible con PHP 4 que no es un lenguaje orientado a objetos completo.

== Design patterns Estructurales (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns estructurales particulares.

== Design patterns de Comportamiento (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns de Comportamiento particulares.

== Design patterns enterprise (Martin Fowler) ==

=== Motivos de organización del código ===

[[wikipedia:Martin Fowler|Martin Fowler]] ha identificado 3 métodos de organización de código llamados '''principios''':
* El '''Transaction Script''' (El código es lineal en función de una acción del usuario).
Es el antiguo principio utilizado en los lenguajes de procedimiento.
Inconveniente: Redundancia de código. Necesidad de conocer el modelo físico a desarrollar.
* El '''Domain Model'''
Es un modelo posible desde los lenguajes orientados a objeto. Son procedimentos funcionales (que deben de ser indentificados antes) que sirven de base para las clases objeto.
Inconveniente: Motivo de mantenimiento complejo.
* El '''Table Module'''
Un intermedio entre los 2 anteriores donde se tiene una sola clase por tabla de la base de datos.

-> Como se muestra en el código de la plantilla (ver sección anterior) Dolibarr se basa en el principio de '''Table Module'''.

=== Comunicación lógica de negociado - datos (ORM) ===

Existen 3 tipos de conexiones:
* '''Data Gateway a tablas y filas'''
Es el más simple. Creamos una tabla por clase y cada clase es un puente con la tabla correspondiente, ver una clase por línea tabla. Una instancia de la clase será pues un registro de la tabla. La clase contiene sólo el código de acceso a líneas o columnas de tablas.

Ejemplo: Es el método utilizado al utilizar ciertos Frameworks de ORM como '''iBatis''' (http://ibatis.apache.org/).

* El '''Active Record'''
Idéntico al anterior, pero podemos añadir algunas funciones de negociado en la clase, siempre que estas funciones sean exclusivas de la tabla o la grabación.

Ejemplo: Es el método utilizado por los desarrollos de Dolibarr y por otras muchas aplicaciones en PHP que disponen de su propio propio framework y prácticas de desarrollo.

* El '''Data Mapper'''
Las clases representan las entidades del problema y no los datos. Por lo tanto hay que doblar, triplicar... estas clases con clases de mapeo para acceder a los datos.
Más "purista" en el papel ya que el negociado está más cercano, este método también tiene la desventaja de ser más complejo en la práctica.
Ejemplo: Es el utilizadao si utilizamos el Framework de ORM '''Propel''' (http://propel.phpdb.org/trac/). Lo encontraremos pues en aplicacciones más pesadas basadas en este ORM.

-> Para los desarrollos de Dolibarr, es recomendado utilizar el modo '''Active Record ''' que ofrece las ventajas de un modelo cercano de negociado sin la complejidad y sin dificultar mucho la técnica. Es en este modo mediante el cual el desarrollo, la comprensión del código y el mantenimiento técnico y/o funcional parece ser la más productivo (Sin embargo, se trata de un eterno debate entre los puristas y los pragmáticos, el debate en el que nadie puede realmente estar en lo cierto, porque todo depende de los objetivos a atender).

Lenguaje y Normas de Desarrollo

2011-06-08T20:47:35Z

Gnovaro: Normas archivos

{{TemplateDocDesarrollo}}

He aquí algunas normas sobre el lenguaje, la sintaxis y las norma de desarrollo en vigor para el proyecto Dolibarr:

= Versiones =

* Dolibarr debe funcionar con:
# Todos los SO (Windows, Linux, MACOS...)
# PHP 4.3 ó + (Debe funcionar sin ningún módulo PHP complementario, exceptuando los módulos de acceso a la base de datos).
# Mysql 3.1 ó +

= Normas Archivos =
* Saltos de linea
* Espacios y tabs

= Normas PHP =

* Dolibarr está escrito en PHP y soporta todas las versiones de PHP superiores a la 4.1. Todos los archivos deben de contener la extensión .php

* La llamada a las variables superglobales PHP deben pasar a través de los operadores dedicados $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Los otros operadores ($HTTP_SERVER_GET, ...) están siendo depreciados en el seno de PHP, no deben de ser ya utilizados. Por lo tanto, el código debe funcionar incluso cuando la opción '''register_long_arrays''' esté en off.
Además de que el código debe funcionar cuando la opción de PHP '''register_globals''' esté en off (recomendado por PHP), también lo deberá hacer cuando la opción '''register_globals''' esté en on (por defecto en muchas instalaciones).

* Los smart tags PHP no són utilizados. Las secciones de código deben de empezar por '''<?php'''

* No se permite el uso de la variable '''PHP_SELF'''. Utilice en su lugar $_SERVER["PHP_SELF"]

* Cuando varias variables deben ser inicializadas con el mismo valor, utilize múltiples líneas
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
en lugar de
<source lang="php">
$var1=$var2=$var3=1;
</source>
que es menos eficiente.

* las cadenas deben de ser encuadradas con comillas simples y las variables sacadas de la cadena.
<source lang="php">
print 'Mi texo muestra mi '.$variable.' !';
</source>

* Los comentarios deben seguir la sintaxis de C, es decir, una doble barra invertida para una línea de comentario y el uso de una barra con arterisco para abrir un bloque de varias líneas
<source lang="php">
/* Bloque de comentarios
*
* Fin el bloque
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// comentario de una línea
print $i;
}

</source>

* Los ficheros deben ser guardados en formato Unix (LF) y no en formato Windows (CR/LF). El formato Unix es compatible con los SO Unix, Windows, Mac, mientras que el formato de archivo de texto de Windows es problemático en algunos PHP en Unix.

Las funciones deben devolver >0 en caso de éxito, y un número <0 en caso de error.
A día de hoy, muy pocas funciones cumplen este standard, pero es necesario.

= Normas SQL =

* ¡Los SELECT * están prohibidos! Cada Select deberá especificar la lista completa de los campos para recuperar. Esto permitirá evitar confusiones. Ejemplo:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* En las consultas SQL, entrecomillaremos los campos, pero no los numéricos que contengan cantidades que se almacenen en los campos de tipo double o real. Los entrecomillados en los numéricos de tipo float se almacenan con un valor diferente. Por ejemplo 412.62 dentro del insert se guardara con el valor 412.61999512 en base si el campo es de tipo double(24,8). Y PHP sólo ve 412.61999512. Otras herramientas verán 412.62 dando la impresión de que no hay problemas. Y PHP tiene razón, hay un problema en base. Mediante la eliminación de las comillas en los numéricos, esto irá mejor.

Ejemplo:
<source lang="sql">
Bien:INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mal: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Nota, el problema de los float es general y no sólamete en el acceso a la base de datos, está presente en todos los lenguajes cuando trabajamos sobre números reales, por lo que deberán ser limpiados por la función price2num con el segundo parámetro rellenado con:
'MU', 'MT' ó 'MS' según sea necesario. Consulte el capítulo "Los números reales, importes y cálculos" más abajo.

En la práctica, con la finalidad de set compatible con todas las precisiones de los paises, utilizaremos los siguientes tipos:
- double(24,8) para cualquier importe
- double(6,3) para las tasas de IVA
- real para una cantidad

* Dolibarr debe trabajar incluso con la opción '''strict''' de Mysql activa.
Para activarla, añada la siguiente línea en su archivo config del servidor MySql (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* las funciones NOW ó SYSDATE están prohibidas en las órdenes de SQL. Si se necesita indicar la fecha del momento en un campo, el valor debe provenir de PHP y no del motor de la base de datos. Esto además de ofrecer una mejor portabilidad del código, también permite una gestión correcta de la zona horaria.

= Normas HTML =

* Todos los atributos de las etiquetas HTML deben de estar *en minúscula* y entrecomillados con *doble comilla*.

* Los enlaces href deben de ser absolutos. para las páginas, basarse en la function dol_buildpath(). Para las imágenes basarse en la llamada de la función img_picto.
Por ejemplo:
<source lang="php">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
</source>

* Javascript y la llamada a scripts java en las páginas php está fuera de las normas. Si de todas maneras se incluye código javascript, debe estar condicionado mediante el test "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // El código PHP que genera el javascript va aquí
}
</source>

* Las ventanas emergentes no deben de ser utilizadas, exceptuando los tooltips (y quedan condicionados por el punto anterior).

* Los scripts externos son escritos en Perl si no pueden serlo en php, la utilización de otro lenguaje no está prohibido, pero debe de ser discutido priero en la lista de correo de desarrollo. El lenguaje debe de ser dominado al menos por 2 desarrolladores para asegurar el mantenimiento

= Normas Dolibarr y plantillas de código =

== Plantillas de código ==
Para estandarizar el código y acelerar el desarrollo de nuevos componentes en Dolibarr, en la carpeta '''dev/skeletons''' encontraremos 4 plantillas de código preparadas.

* 1 que sirve de ejemplo de descriptor de módulo: '''myModule.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva clase: '''skeleton_class.class.php'''
* 1 que sirve de ejemplo de código para crear una nueva página: '''skeleton_page.php'''
* 1 que sirve de ejemplo de código para crear una nuevo script a ejecutar en línea de comandos: '''skeleton_script.php'''

Úsenlas como ejemplo.
Tenga en cuenta que estas plantillas también son utilizadas por el generador de código PHP que se describe en el capítulo de Desarrollo de módulos Dolibarr módulo para acelerar su desarrollo.

== Las fechas y la Zona Horaria ==
Dolibarr es una aplicación multi-usuario y multi-ubicación. Por lo tanto, es necesario almacenar las fechas en el formato correcto. Para evitar problemas de conversión, deben aplicarse las siguientes reglas:
* Una fecha en memoria debe de estar en formato Timestamp GMT.
* Una fecha guardada en la base de datos contiene el Timestamp GMT en relación con la fecha que figura en la consulta en hora local del servidor PHP. No se trata de las fechas de actualización de la base de datos (campo '''tms''' en la base de datos).
Por lo tanto, el 1 de enero de 1970, a las 3 en París (TZ=+1) = las 2 en Greenwitch (TZ=0) será almacenado en memora 7200 y será enviado a la base de datos con la cadena '19700101030000' (PHP convierte en hora de su TZ y la base de datos la deconvierte con su TZ que es la misma que la de PHP).

Los métodos select deben traducir los campos fecha al formato de cadenta TZ de la base ('19700101030000') mediante la llamada del método db->jdate para recuperar la información en memoria en formato Timestamp GMT. Y los métodos insert deben deben generar la petición convirtiendo la fecha en memoria conocida en variable, mediante el método db->idate (Ver ejemplos generados por la plantilla).

* Las actualizaciones automáticas de la base de datos (campo '''tms''' en la base) contienen el Timestamp GMT del momento en que se ha realizado la modificación. Los métodos select recuperan directamente este dato en memoria en formato Timestamp GMT.

== Codificación UTF8/ISO ==
Dolibarr guarda la información de la manera siguiente:

* En la base de datos, los datos en UTF8 ó ISO. Esto depende del pagecode de la base de datos, y por lo tanto, de las opciones en la creación de esta base de datos. En todos los casos, el controlador de base de datos Dolibarr (dentro de /lib/database) lee e inserta por conversión desde y hacia UTF8.
* Los datos en memoria se guardan en UTF8 (instancias de objetos PHP).
* las páginas web mostradas en pantalla se encuentran en formato UTF8 (con versiones < 2.5.1, es el antiguo parámetro $character_set del fichero conf.php quien define el formato de salida).

== Los números reales, importes y cálculos ==
Tanto en PHP como en otros lenguajes (Java, por ejemplo), los datos no enteros (float, real, double) no son fialbes.
Pruebe a realizar por ejemplo
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
No obtendrá 0, sino un número muy pequeño en potencia 10 negativo . Si obtiene cero, puede encontrar otros ejemplos que no funcionan.
El problema de los float es general, una variable resultante del cálculo de números reales debe SISTEMATICAMENTE ser limpiada mediante la función price2num con el segundo parámetro rellenado con: 'MU', 'MT' ó 'MS' según el caso (ver doc de la función).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
Si no es un precio que se ajuste a los parámetros de MU, MT, MS debe utilizar la función '''round()'''.

== Creación de tablas ==
No crear una tabla a utilizar, es decir, al '''primer uso''' del módulo.
Si crea un módulo que usa tablas que no se incluyen como estándar en el código de Dolibarr, asegúrese de seguir el tutorial Creación de un módulo que explica cómo incluir las tablas que se crean en la activación del módulo y no en su uso (ver más arriba).

== Logs ==
Añada traces dentro de su código mediante la función dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Carpetas de trabajo ==
Si tiene que crear una carpeta de trabajo, en el código, haga referencia a esta carpeta de la siguiente forma
DOL_DATA_ROOT.'/mimodulo'.
La carpeta puede crearse en desde su código mediante el código siguiente:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/mimodulo';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si necesita una carpeta de datos temporales, esta carpeta deberá ser DOL_DATA_ROOT.'/minmodulo/temp'

= Design patterns y programación con objetos =
== Design patterns Creacionales (GoF) ==
Design patterns definidos por el le Gang Of Four (ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns creacionales particulares.
Hay objetos cercanos a los Singleton y creados conforme al 100% en el espíritu, pero no en la sintaxis, a fin de ser compatible con PHP 4 que no es un lenguaje orientado a objetos completo.

== Design patterns Estructurales (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns estructurales particulares.

== Design patterns de Comportamiento (GoF) ==
(ver la wikipedia sobre los [http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o Design patterns]).
No hay design patterns de Comportamiento particulares.

== Design patterns enterprise (Martin Fowler) ==

=== Motivos de organización del código ===

[[wikipedia:Martin Fowler|Martin Fowler]] ha identificado 3 métodos de organización de código llamados '''principios''':
* El '''Transaction Script''' (El código es lineal en función de una acción del usuario).
Es el antiguo principio utilizado en los lenguajes de procedimiento.
Inconveniente: Redundancia de código. Necesidad de conocer el modelo físico a desarrollar.
* El '''Domain Model'''
Es un modelo posible desde los lenguajes orientados a objeto. Son procedimentos funcionales (que deben de ser indentificados antes) que sirven de base para las clases objeto.
Inconveniente: Motivo de mantenimiento complejo.
* El '''Table Module'''
Un intermedio entre los 2 anteriores donde se tiene una sola clase por tabla de la base de datos.

-> Como se muestra en el código de la plantilla (ver sección anterior) Dolibarr se basa en el principio de '''Table Module'''.

=== Comunicación lógica de negociado - datos (ORM) ===

Existen 3 tipos de conexiones:
* '''Data Gateway a tablas y filas'''
Es el más simple. Creamos una tabla por clase y cada clase es un puente con la tabla correspondiente, ver una clase por línea tabla. Una instancia de la clase será pues un registro de la tabla. La clase contiene sólo el código de acceso a líneas o columnas de tablas.

Ejemplo: Es el método utilizado al utilizar ciertos Frameworks de ORM como '''iBatis''' (http://ibatis.apache.org/).

* El '''Active Record'''
Idéntico al anterior, pero podemos añadir algunas funciones de negociado en la clase, siempre que estas funciones sean exclusivas de la tabla o la grabación.

Ejemplo: Es el método utilizado por los desarrollos de Dolibarr y por otras muchas aplicaciones en PHP que disponen de su propio propio framework y prácticas de desarrollo.

* El '''Data Mapper'''
Las clases representan las entidades del problema y no los datos. Por lo tanto hay que doblar, triplicar... estas clases con clases de mapeo para acceder a los datos.
Más "purista" en el papel ya que el negociado está más cercano, este método también tiene la desventaja de ser más complejo en la práctica.
Ejemplo: Es el utilizadao si utilizamos el Framework de ORM '''Propel''' (http://propel.phpdb.org/trac/). Lo encontraremos pues en aplicacciones más pesadas basadas en este ORM.

-> Para los desarrollos de Dolibarr, es recomendado utilizar el modo '''Active Record ''' que ofrece las ventajas de un modelo cercano de negociado sin la complejidad y sin dificultar mucho la técnica. Es en este modo mediante el cual el desarrollo, la comprensión del código y el mantenimiento técnico y/o funcional parece ser la más productivo (Sin embargo, se trata de un eterno debate entre los puristas y los pragmáticos, el debate en el que nadie puede realmente estar en lo cierto, porque todo depende de los objetivos a atender).

Langages et normes

2011-06-08T20:46:13Z

Gnovaro: add Normes Fichiers

{{TemplateDocDev}}

Voici les quelques règles sur le langage, la syntaxe et normes de développement en vigueur pour le projet Dolibarr:

= Versions =

* Dolibarr doit fonctionner sur:
# Tous OS (Windows, Linux, MACOS...)
# PHP 4.3 ou + (Doit fonctionner sans aucun module PHP complémentaire hors les modules d'accès base de donnée).
# Mysql 3.1 ou +

= Normes Fichiers =
* Retours à la ligne
* Les espaces et les onglets

= Normes PHP =

* Dolibarr est écrit en PHP et supporte toutes versions PHP supérieures à la 4.1. Les fichiers doivent tous comporter l'extension .php

* L'appel aux variables superglobales PHP doit passer par les opérateurs dédiés $_GET, $_POST, $_COOKIES, $_SERVER, $_ENV.
Les autres opérateurs ($HTTP_SERVER_GET, ...) ayant été passés en deprecated au sein de PHP, ne doivent plus être utilisés. Ainsi le code doit fonctionner y compris quand l'option '''register_long_arrays''' est à off.
De plus, le code doit fonctionner quand l'option PHP '''register_globals''' est à off (recommandé par PHP) aussi bien que quand l'option '''register_globals''' à on (par défaut sur de nombreuses installations).

* Les smart tags PHP ne sont pas utilisés. Les sections de code doivent commencer par '''<?php'''

* Pas d'utilisation de la variable '''PHP_SELF'''. Utiliser a la place $_SERVER["PHP_SELF"]

* Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs lignes
<source lang="php">
$var1=1;$var2=1;$var3=1;
</source>
plutôt que
<source lang="php">
$var1=$var2=$var3=1;
</source>
qui est moins performant.

* Les chaines doivent être encadrées de simple quote et les variables sorties de la chaine.
<source lang="php">
print 'Mon texte affiche ma '.$variable.' !';
</source>

* Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation slash-étoile pour ouvrir un bloc de plusieurs lignes
<source lang="php">
/* Bloc de commentaire
*
* Fin du bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// commentaire sur une ligne
print $i;
}

</source>

* Les fichiers doivent être sauvés en format Unix (LF) et non Windows (CR/LF). Le format Unix étant compatible sur les OS Unix like, Windows, Mac, alors que le format fichier texte Windows pose problème sous certains PHP sous Unix.

Les fonctions doivent retourner une valeure strictement > à 0 en cas de succès, et un nombre < à 0 en cas d'erreur.

= Normes SQL =

* Les SELECT * sont interdits ! Chaque SELECT doit spécifier la liste complète des champs à récupérer. Cela permet d'éviter les confusions. Exemple:
<source lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</source>

* Dans les requêtes SQL, on quote les champs mais pas les numériques qui contiennent des montants destinés à être stockés dans des champs de type double ou real. Les quotes sur les numériques de type float provoquent parfois un stockage d'une valeur différente. Par exemple 412.62 dans le insert sera en fait stocké avec la valeur 412.61999512 en base si le champ est de type double(24,8). Et seul le PHP voit 412.61999512. Les autres outils verront 412.62 donnant l'impression qu'il n'y a pas de problème. Et c'est le PHP qui a raison, il y a problème en base. En supprimant les quotes sur les numériques, cela va mieux.

Exemple:
<source lang="sql">
Bon: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mauvais: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</source>

Remarque, le pb des float est général et pas seulement sur les accès base, il est présent dans tous les languages quand on travaille sur des nombres réels, aussi ils doivent être, dès que affectés, nettoyés par la fonction price2num avec le 2eme paramètre renseigné à:
'MU', 'MT' ou 'MS' selon le besoin.
Voir aussi le chapitre "Les nombres réels, montants et calculs" plus bas.

Dans la pratique, afin d'etre compatible avec toutes les précisions des pays, on utilisera les types suivants:
- double(24,8) pour tout montant
- double(6,3) pour les taux de tva
- real pour une quantité

* Dolibarr doit fonctionner même avec l'option '''strict''' de Mysql active.
Pour l'activer, ajouter la ligne suivante dans le fichier config du serveur Mysql (my.cnf)
<source lang="ini">
sql-mode="STRICT_ALL_TABLES"
</source>

* Les fonctions NOW ou SYSDATE sont interdites au sein des ordres SQL. S'il faut saisir la date du moment dans un champ, la valeur doit venir du PHP et non du moteur de base de données. Ceci afin d'avoir une meilleure portabilité du code mais surtout d'avoir une gestion correcte des TimeZone.

= Normes HTML =

* Tous les attributs dans les balises HTML doivent être *en minuscule* et quotés avec des *doubles quote*.

* Les liens href doivent être absolus en se basant sur la fonction dol_buildpath() pour obtenir un chemin absolu depuis un chemin relatif au répertoire htdocs. Pour les tags img, il faut faire appel à la fonction img_picto().
Par example:
<source lang="php">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
</source>

* Le javascript et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript"
<source lang="php">
if ($conf->use_javascript)
{
... // Le code php qui génère du javascript est ici
}
</source>

* Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent conditionnées par le point ci-dessus).

* Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs. Le langage devra être maitrisé par au moins 2 développeurs pour en assurer la maintenance.

= Normes Dolibarr et squelettes de code =

== Squelettes de code ==
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire '''dev/skeletons''', 4 squelettes de code tout préparés.

* 1 qui sert d'exemple de descripteur de module: '''myModule.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle classe: '''skeleton_class.class.php'''
* 1 qui sert d'exemple de code pour faire une nouvelle page: '''skeleton_page.php'''
* 1 qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: '''skeleton_script.php'''

Servez-vous en comme exemple.
Notons que ces squelettes sont aussi utilisés par le générateur de code PHP qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développement.

== Les dates et TimeZone ==
Dolibarr se veut une application multi-utilisateur et multi-localisation. Il convient donc de stocker les dates dans le bon format. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées:
* Une date en mémoire doit être au format Timestamp GMT.
* Une date stockée en base de données contient le Timestamp issue de la date soumise dans la requête en heure locale du serveur PHP. Cela ne concerne pas les dates mises à jour automatiquement par la base (champ '''tms''' en base).
Ainsi le 1er janvier 1970, 3 heures à Paris (TZ=+1) = 1er janvier 1970, 2 heures à Greenwich (TZ=0) sera stocké en mémoire par 7200 et sera soumis à la base de données avec la chaine '19700101030000' (PHP convertit en heure de son TZ et la base déconvertit avec son TZ qui est le même que celui de PHP).

Les méthodes select doivent donc traduire les champs dates lus qui sont au format chaine TZ de la base ('19700101030000') par appel de la méthode db->jdate afin de récupérer une information en mémoire au format Timestamp GMT. Et les méthodes insert doivent lors de la génération de la requête convertir la date mémoire connue en variable, par la méthode db->idate (Voir exemples générés par le squelette).

* Les dates mises à jour automatiquement par la base (champ '''tms''' en base) contiennent le Timestamp où la modification est faite selon le timezone de la base de donnée. Les méthodes select récupèrent directement cette donnée en mémoire au format Timestamp GMT. Si le timezone de la base de donnée diffère de celui du PHP (un des 2 est mal réglé), il peut donc y avoir des écarts entre date de création et modification.

== L'encodage UTF8/ISO ==
Dolibarr stocke les informations de manière suivante:
* En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
* Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
* Les pages web affichées à l'écran sont au format UTF8 (avec les versions < 2.5.1, c'est le vieux paramètre $character_set du fichier conf.php qui définissait le format de sortie).

== Les nombres réels, montants et calculs ==
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables.
Essayer de faire par exemple
<source lang="php">
print 239.2 - 229.3 - 9.9;
</source>
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas.
Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction price2num avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
<source lang="php">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</source>
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction '''round()'''.

== Création de tables ==
Ne pas créer de table à l'utilisation, c'est-à-dire à la '''première utilisation''' du module.
Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel Créer un module qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).

== Logs ==
Ajouter des traces dans votre code avec la fonction
dolibarr_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);

== Répertoires de travail ==
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par
DOL_DATA_ROOT.'/monmodule'.
Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
<source lang="php">
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
if (! is_dir($mymoduledir)) create_exdir($mymoduledir);
</source>

Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être DOL_DATA_ROOT.'/monmodule/temp'

= Design patterns et programmation objet =

== Design patterns de Création (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de création particulier.
On trouve des objets proches des Singletons et Fabriques conforme à 100% dans l'esprit mais pas dans la syntaxe, ceci afin d'etre compatible avec le PHP 4 qui n'est pas un langage objet complet.

== Design patterns de Structure (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de structure particulier.

== Design patterns de Comportement (GoF) ==
Design patterns défini par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Pas de mise en oeuvre de design patterns de comportement particulier.

== Design patterns d'entreprises (Martin Fowler) ==

=== Mode d'organisation du code ===
[[wikipedia:Martin_Fowler|Martin Fowler]] a identifié 3 méthodes d'organisation du code appelées '''patterns''' ('''motifs'''):
* Le '''Transaction Script''' (Le code est linéraire en fonction d'une action utilisateur).
C'est le motif à l'ancienne utilisé dans les langages procéduraux.
Inconvénient: Redondance du code. Nécessité de connaitre le modèle physique pour développer les parties métiers.
* Le '''Domain Model'''
C'est un concept possible depuis les langages objets. Ce sont les procédures métiers (qui doivent être identifiés avant) qui servent de bases pour les classes objets.
Inconvénient: Motif complexe à maintenir.
* Le '''Table Module'''
Un intermédiaire entre les 2 précédents où l'on a une instance unique de classe par table de la base de données.

-> Comme le montre les squelettes de code (voir point précédent), Dolibarr se base sur le principe du '''Table Module'''.

=== Communication Logique métier - Données (ORM) ===
Il existe 3 modes de liaisons:
* Le '''Table And Row Data Gateway'''
C'est le plus simple. On crée une table par classe et chaque classe est un pont avec la table correspondante, voir une classe par ligne de table. Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables. Le code métier doit alors être ajouté dans d'autres classes. Les liens entre ces classes tables et les classes métiers devant être connues ou déduite de la connaissance du développeur.

Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme '''iBatis''' (http://ibatis.apache.org/).

* Le '''Active Record'''
Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à conditions que ces fonctions soient propres à la table ou à l'enregistrement. C'est le pattern qui offre le meilleur rapport fonctionnalité/complexité.

Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développements.

* Le '''Data Mapper'''
Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données.
Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être plus complexe sur le plan pratique.
Exemple: C'est le choix si on utilise le Framework d'ORM '''Propel''' (http://propel.phpdb.org/trac/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.

-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).

Configuration par statut

2011-05-02T19:59:53Z

Gnovaro: Se agrega informacion de las socieades de argentina

[[Category:Administrative]]

{{Flag en}} This page describes main status for organizations or companies, by country, and the Dolibarr setup you should use.

{{Flag fr}} Cette page décrit les principaux statuts d'institutions/sociétés par pays ainsi que le paramétrage à suivre dans Dolibarr.

{{flag sp}} Esta página describe los principales estatutos de empresas/instituciones por país, así como la configuración a seguir en Dolibarr.

= {{Flag fr}} France =

En italique, les informations à vérifier (non confirmées).

{|class="wikitable" style="text-align:center; width:80%;"
|-
! scope=col | Statut juridique
! scope=col | Création
! scope=col | Conditions
! scope=col | Choix BNC
! scope=col | Choix TVA
! scope=col | Impots Sociétés
ou Impots revenus (BIC/BNC)
! scope=col | Charges TVA
! scope=col | Taxes pro
! scope=col | Bilan compta
! scope=col | Rem
! scope=col | Param Dolibarr
|-
! scope=row | Indépendant/Libéral en micro entreprise
|Formulaire URSSAF sur http://www.cfe.urssaf.fr
|CA < 32K EUR pour services
< 80K EUR pour produits
|Régime déclaratif spécial
|TVA en franchise
|Revenu à mettre sur décla 2042P en zone BNC avec
décla impot 2042.
Montant impots = (CA - 25% de forfait de charges) sur barème
impôt revenu (en plus autres revenus perso).
|Pas de décla et pas de paiement TVA
|Taxe pro
''Déclaration ?''
|?
|Mention sur factures
"TVA non applicable, article 293 B du CGI"
|?
|-
! scope=row | Indépentant/Libéral
|Formulaire URSSAF sur http://www.cfe.urssaf.fr
|CA > 32K et < 230K EUR pour services

CA > 80K et < 763K EUR pour produits
|Régime déclaratif contrôlé
|TVA simplifié
|Déclaration revenus pro http://www.net-entreprises.fr (< 1er mai)
|???
|Taxe pro
''Déclaration ?''
|?
|Obligation d'accepter les chèques si membre d'une AGA
|?
|-
! scope=row |Autoentrepreneur
|En ligne sur http://www.lautoentrepreneur.fr
|?
|Régime déclaratif spécial
|TVA en franchise
|Déclaration trimestrielle ou mensuelle revenus pro
sur http://www.lautoentrepreneur.fr
|Pas de décla et pas de paiement TVA
|?
|?
|Mention sur factures
"TVA non applicable, article 293 B du CGI"
|?
|-
! scope=row |Profession libérale médicale (médecin)
|Formulaire Cerfa dépendant de profession à la DDASS pour numéro ADELI

Formulaire URSSAF pour chomage

CPAM pour maladie+Carte CPS

CARMF pour retraite

Centre impot pour taxe pro
|CA >32K et <230K EUR
|Régime déclaratif contrôlé
|Non assujeti
|Revenu pro mis sur formulaire 2035 dans zone BNC,
envoyé aux impôts ou à son AGA si membre d'une AGA
(<1er mai)

Report sur décla impot 2042C (Case D5QC=rev comm prof) des recettes (gain-dépenses) dans zone BNC.
|Non assujeti
|Taxe pro, c'est la 2035 qui fait office de décla
(exempt sous certaines conditions, rares)
|?
|Obligation d'accepter les chèques si membre d'une AGA
|?
|-
! scope=row | SARL
|CFE du Greffe ou http://www.cfenet.cci.fr/
|CA >32K et <230K EUR
|Régime déclaratif contrôlé
|TVA réel simplifié
|Formulaire 2065 pour déclarer l'année d'avant (< 1er mai)
Formulaire 2572 (Cerfa 12404) pour payer (< 1er mai)
|Formulaire 3517-CA12 (Cerfa 11417) / an + paiement
Décla/paiements par
*TéléTVA-EFI
*TéléTVA-EDI si CA > 760K EUR,
*TDFC si CA > 15M EUR
Fait par expert-comptable ou soi-même (< 1er mai).
|Taxe pro
''Formulaire 1003 (CERFA 11067*10) pour déclarer annuellement (< 1er mai)''
|''Formulaire 2052 ?''
Formulaire 2065 (+ tableaux 2033A à 2033G)
|Et Formulaire DAS2-T (< 1er mai)
|?
|-
! scope=row | SARL
|CFE du Greffe ou http://www.cfenet.cci.fr/
|CA > 230K EUR
|Régime déclaratif contrôlé
|TVA réel normal
|Formulaire 2065 pour déclarer l'année d'avant (< 1er mai)
Formulaire 2572 (Cerfa 12404) pour payer (< 1er mai)
|Formulaire 3310-CA3 (Cerfa 10963) / mois ou trimestre + paiement
Décla/paiements par
*TéléTVA-EFI
*TéléTVA-EDI si CA > 760K EUR
*TDFC si CA > 15M EUR
Fait par expert-comptable ou soi-même.
|Taxe pro
''Formulaire 1003 (CERFA 11067*10) pour déclarer annuellement (< 1er mai)''
|''Formulaire 2052 ?''
Formulaire 2065 (+ tableaux 2050 à 2059G)
|Et Formulaire DAS2-T (< 1er mai)
|?
|}

{{cite web|url=http://www.rhonealpes.experts-comptables.fr/backoffice/fichiers_upload/actualites/4%20G-1-09.pdf|accessdate=2009-03-28 }}

= {{Flag sp}} Spain/Espagne =

{|class="wikitable" style="text-align:center; width:80%;"
|-
! scope=col | Forma jurídica
! scope=col | Creación
! scope=col | Condiciones
! scope=col | Acogido IRPF
! scope=col | Acogido IVA
! scope=col | Impuesto sociedades
! scope=col | Dec. Trimestrales
! scope=col | Dec. Anuales
! scope=col | Notas
! scope=col | Param Dolibarr
|-
! scope=row | Autónomo
| 1.- Alta en la Declaración Censal (modelo 036)
2.- Alta en el IAE (mismo modelo 036 si no tributa, modelos 840/848 si tributa),
3.- Alta en el Régimen de Autónomos de la Seg. Social
| 1 socio. Sin límite de capital. Responsabilidad ilimitada
| Sí
| Sí
| No
| -Declaración IVA (modelo 303)
-Pagos fraccionados a cuenta IRPF (modelos 130 y 131)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración IRPF (modelo D-100)
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Sociedad Civil
| 1.- Redacción de contrato privado entre las partes
2.- Pago del Impuesto de Transmisiones Patrimoniales (modelo 600)
3.- Solicitud CIF, Declaración Censal e IAE
4.- Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 2 o más socios. Sin límite de capital. Responsabilidad ilimitada
| Sí
| Sí
| No
| -Declaración IVA (modelo 303)
-Pagos fraccionados a cuenta IRPF (modelos 130 y 131)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración IRPF (modelo D-100)
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Comunidad de Bienes
| 1.- Redacción de contrato privado entre las partes
2.- Pago del Impuesto de Transmisiones Patrimoniales (modelo 600)
3.- Solicitud CIF, Declaración Censal e IAE
4.- Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 2 o más socios. Sin límite de capital. Responsabilidad ilimitada
| Sí
| Sí
| No
| -Declaración IVA (modelo 303)
-Pagos fraccionados a cuenta IRPF (modelos 130 y 131)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración IRPF (modelo D-100)
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Sociedad Limitada
| 1.- Solicitud del Certificado de Denominación Social
2.- Apertura de Cuenta Bancaria
3.- Redacción de Estatutos y firma de Escritura de Constitución
4.- Pago Impuesto de Transmisiones Patrimoniales
5.- Inscripción en el Registro Mercantil
6.-Solicitud CIF, Declaración Censal e IAE
7.-Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 2 o más socios. Capital mínimo 3006 €. Responsabilidad limitada al capital
| No
| Sí
| Sí
| -Declaración IVA (modelo 303)
-pagos fraccionados a cuenta (modelo 202)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración del Impuesto de Sociedades.
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Sociedad Anónima
| 1.- Solicitud del Certificado de Denominación Social
2.- Apertura de Cuenta Bancaria
3.- Redacción de Estatutos y firma de Escritura de Constitución
4.- Pago Impuesto de Transmisiones Patrimoniales
5.- Inscripción en el Registro Mercantil
6.-Solicitud CIF, Declaración Censal e IAE
7.-Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 2 o más socios. Capital mínimo 60101 €. Responsabilidad limitada al capital
| No
| Sí
| Sí
| -Declaración IVA (modelo 303)
-pagos fraccionados a cuenta (modelo 202)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración del Impuesto de Sociedades.
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Sociedad Limitada Laboral
| 1.- Solicitud del Certificado de Denominación Social
2.- Apertura de Cuenta Bancaria
3.- Redacción de Estatutos y firma de Escritura de Constitución
4.- Pago Impuesto de Transmisiones Patrimoniales
5.- Inscripción en el Registro Mercantil y de Sociedades Laborales
6.-Solicitud CIF, Declaración Censal e IAE
7.-Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 3 o más socios. Capital mínimo 3006 €. Responsabilidad limitada al capital
| No
| Sí
| Sí
| -Declaración IVA (modelo 303)
-pagos fraccionados a cuenta (modelo 202)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración del Impuesto de Sociedades.
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Sociedad Anónima Laboral
| 1.- Solicitud del Certificado de Denominación Social
2.- Apertura de Cuenta Bancaria
3.- Redacción de Estatutos y firma de Escritura de Constitución
4.- Pago Impuesto de Transmisiones Patrimoniales
5.- Inscripción en el Registro Mercantil y de Sociedades Laborales
6.-Solicitud CIF, Declaración Censal e IAE
7.-Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 3 o más socios. Capital mínimo 60101 €. Responsabilidad limitada al capital
| No
| Sí
| Sí
| -Declaración IVA (modelo 303)
-pagos fraccionados a cuenta (modelo 202)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración del Impuesto de Sociedades.
-Declaración operaciones con terceros (modelo 347)
|
|?
|-
! scope=row | Cooperativa
| 1.- Solicitud del Certificado de Denominación Social
2.- Apertura de Cuenta Bancaria
3.- Redacción de Estatutos y firma de Escritura de Constitución
4.- Pago Impuesto de Transmisiones Patrimoniales
5.- Inscripción en el Registro de Cooperativas
6.-Solicitud CIF, Declaración Censal e IAE
7.-Alta en el Régimen de Autónomos y/o General de socios y trabajadores
| 3 o más socios. Capital mínimo 1803 €. Responsabilidad limitada al capital
| No
| Sí
| Sí
| -Declaración IVA (modelo 303)
-pagos fraccionados a cuenta (modelo 202)
-Pagos sometidos a retención (modelos 110 y 190)
| -Declaración del Impuesto de Sociedades.
-Declaración operaciones con terceros (modelo 347)
|
|?
|}

{{cite web|url=http://www.crear-empresas.com}}

= {{Flag ar}} Argentine/Argentine/Argentina =

{|class="wikitable" style="text-align:center; width:80%;"
|-
! scope=col | Forma jurídica
! scope=col | Creación
! scope=col | Condiciones
! scope=col | IVA
! scope=col | Impuesto sociedades
! scope=col | Dec. Trimestrales
! scope=col | Dec. Anuales
! scope=col | Notas
! scope=col | Param Dolibarr
|-
|-
| Responsable inscripto
|-
|-
| Responsable NO inscripto
|-
|-
| Exento
|-
|}