Le Tue, 22 Apr 2014 18:25:34 +0200, Eric Chatellier <chatellier@codelutin.com> a écrit :

Le 22/04/2014 18:20, Olivia Bruce a écrit :

...

Selon la discussion que l'on a eu dans le bureau, j'ai cru comprendre que la v1 avait été conçu de façon à ce qu'on ait qu'un temps par jour? Pourtant l'application permet l'émission de plusieurs temps pour une journée ou du moins la v2.

Quels sont les raisons derrière ce choix?

C'était une contrainte de developpement car le format de stockage a été repris de gTimer qui comptait une durée par jour. On aurait très bien pu faire le même choix même si la contrainte n'avait pas existé.

Ce choix peut changer pour la V2 s'il a un intérêt ou qu'il résouds des problèmes. Sinon, j'ai toujours une préférence pour la simplicité, 1 jour, 1 temps :p

Si cela a été fait plus par contrainte que par choix, en supprimant cette contrainte de stockage, il devient possible de mieux réfléchir sur la modélisation. Comme évoquer oralement, je suis favorable à des temps qui auraient un début et une fin (à la limite bornés sur un jour). Cela apporte plus de visibilité sur les tâches, et ça peut permettre à l'avenir des features sympatiques (vue "calendrier" des temps passés, statistiques sur l'organisation...) De plus, avoir des temps "bornés" permet d'obtenir des durées/jour. L'inverse n'est pas possible par contre. Donc dans l'optique d'une intégration/interraction avec des modules extérieurs, il me semble plus judicieux d'avoir un stockage qui soit le plus "branchable" possible : si en face il faut une période, ce sera connectable, s'il faut juste une durée, ça se calcule et ce sera donc connectable. La simplicité n'est pas forcément là ou la réflexion est plus rapide :) -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28