Re: [Dolibarr-dev] les incohérences

[Régis Houssin]

oui et bien moi en tant que développeur je suis assez fatigué de
chercher des bugs au deux endroits, tu as un code ajax il ya un bug tu
cherches dans le code ajax, ici il faut chercher de partout et corriger
deux fois pour ne pas rendre l'un ou l'autre fonctionnement bancale

de plus ça double le code

nous avançons à grand pas dans le fork de dolibarr version nosql et je
peux vous dire qu'on fait du ménage au profit du jquery et on divise par
2 les lignes de codes...

rien que la page facture.php est imbuvable quand il faut trouver quelque
chose ! :-))


Le 08/06/12 20:50, Ozit a écrit :
> En tant qu'utilisateur, je suis de l'avis d'LD.
> 
> Le 08/06/2012 20:40, Laurent Destailleur (eldy) a écrit :
>> Je dirais que dans 100% des cas l'utilisateur choisi javascript.
>> Mais l'interet n'est pas la. Le but est d'assuré qu'il y a bien une
>> isolation entre le code coté serveur et coté client et qu'il n'y a pas
>> de code croisé. Du genre un debut d'action qui est mis coté serveur
>> avec une fin coté client.
>> Des tonnes de bugs ont été trouvé/corrigé grace a cela pour un sucrout
>> nul (car c'est un simple if a jouter). Et si cela genere un bug
>> quelque part, c'est qu'il y avait un bug ailleurs, d'ou tout l'interet.
>> Cela garanti aussi une meilleure isolation permettant d'interchanger
>> les technos ou librairies plus facillement (exemple la suppression des
>> lib graphique en javascript faite en 1 heure sur toute l'appli avec
>> garantie de non régression), chose qui aurait été impossible sans cela.
>>
>> L'exemple cité est le bon, il y avait un bug justement sans rapport
>> avec le javascript et c'est cela qui l'a mis en évidence (meme si ma
>> correction récente était incomplete, mais ca c'est une autre
>> histoire). Dopnc avoir des bugs de conceptions majeures qui
>> appraissent au prix d'un simple if a ajouter. Je prend sans hésiter.
>>
>> Etant celui qui assure le plus de correction de bugs (encore 200 juste
>> sur la beta 3.2), je pense être bien placé pour dire que le maintien
>> de la séparation du code de manière rigoureuse fait beaucoup plus
>> gagner de temps qu'en perdre.
>>
>>
>>
>> Le 08/06/2012 16:05, Régis Houssin a écrit :
>>> Bon je persiste et signe
>>>
>>> il faut qu'on fasse un choix soit on s'emmerde avec du "javascript" pas
>>> "javascript", soit on dit javascript par défaut pour certaines
>>> fonctions, car avoir le choix complexifie inutilement l'application et
>>> dans 99% des cas l'utilisateur choisit javascript/ajax
>>>
>>> exemple : avec la dernier snapshot, je veux supprimer un produit il me
>>> le clone après validation. pourquoi ? et bien les connaisseurs regarde
>>> le fichier /product/fiche.php et il comprendront !!
>>>
>>> voilà la condition sur le clonage et la suppression
>>>
>>> if($action=clone || $conf->use_javascript_ajax)
>>>
>>> idem pour l'action delete
>>>
>>>
>>> ce qui donne une activation des deux conditions quoi qu'il arrive si on
>>> utilise javascript, d'où la dernière condition qui prend le dessus,
>>> c'est à dire le clonage lorsqu'on veut faire un delete.
>>>
>>> bref: JE VOTE POUR UN JAVASCRIPT/AJAX PAR DEFAUT !!!
>>>
>>>
>>> Cordialement,
>>
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> 

Cordialement,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------