June 2014 - Jtimer-devel - mailman.cloud.codelutin.com

Génération des rapport jour/semaine/mois/année
by Olivia Bruce June 27, 2014

June 27, 2014

Bonjour, Aujourd'hui je me trouve face à une petite difficulté au niveau de la génération de rapport. Qu'est ce que c'est? C'est le résumé de toutes les tâches et de tous les projets qui ont été minutés entre deux bornes (des dates : dateInf avec heure 00:00:00 et dateSup avec heure 23:59:59) définies par l'utilisateur. Pour retrouver les tâches minutées entre deux bornes, c'est assez facile, la base de données peut aisément calculer par projet la somme des temps et la renvoyer. Ensuite on traite les données pour reconstruire l'arbre, et afficher à l'utilisateur le rapport. Qu'est ce qui pose problème? Sur jTimer v1, il était possible de dissocier par jour/semaine/mois/années les tâches minutées; on souhaite donc rééditer cette fonctionnalité sous jTimer v2. Je souhaiterais pouvoir récupérer mes taches sous la contrainte des bornes avec en plus un groupement par période. Et je n'ai pas trouvé par exemple de façon de classer les taches minutées par semaine directement. 1. Peut être que je me trompe et que des moyens existent de grouper par jour/mois. /semaine/année comme en mysql, si c'est le cas avis au connaisseur pour m'éclairer. 2. Sinon, il faudrait récupérer toutes les données et les traiter ensuite en java pour replacer tous les temps/tâches dans leur période, puis ensuite reconstruire l'arbre pour chaque période. Ce qui peut vite devenir lourd avec un grand nombre de données. 3. Ou encore définir chaque petite période, puis faire appel à la base pour récupérer les tâches avec les temps pour chaque période, puis reconstruire l'arbre pour l'affichage. Mais bon ce n'est pas vraiment conseillé de faire plein de petits accès donc je déconseille. Si quelqu'un a une idée il serait intéressant de m'en faire part, Merci.

2 1

Re: [Jtimer-devel] [Jtimer-commits] r2995 - in branches/ng-jtimer/src/main: java/org/chorem/jtimer/entities java/org/chorem/jtimer/storage java/org/chorem/jtimer/web webapp/js
by Tony Chemit June 5, 2014

June 5, 2014

On Thu, 5 Jun 2014 18:19:13 +0200 (CEST) obruce(a)users.chorem.org wrote: > Added: branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java On pourrait peut-être plutôt utiliser une classe qui existe déjà ? org.apache.commons.lang3.tuple.Pair > =================================================================== > --- branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java (rev 0) > +++ branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java 2014-06-05 16:19:13 UTC (rev 2995) > @@ -0,0 +1,46 @@ > +package org.chorem.jtimer.entities; > + > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > + > +/** > + * Created by olivia on 05/06/14. > + * <p/> > + * Project name : jtimer > + * <p/> > + * Package name : org.chorem.jtimer.entities > + * > + * Cette classe represente un duo d'element type cle/valeur > + * @param <K> la cle > + * @param <V> la valeur > + */ > +public class Pair<K,V>{ > + > + protected static final Log log = LogFactory.getLog(Pair.class); > + > + private K key; //la clef de la pair > + private V value; //la valeur de la pair > + > + public Pair(K key, V value){ > + this.key = key; > + this.value = value; > + > + log.info(this.key.toString() + this.value.toString()); > + } > + > + public V getValue() { > + return value; > + } > + > + public void setValue(V value) { > + this.value = value; > + } > + > + public K getKey() { > + return key; > + } > + > + public void setKey(K key) { > + this.key = key; > + } > +} > -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit(a)codelutin.com twitter: https://twitter.com/tchemit

1 0

Proposition et question
by Olivia Bruce June 4, 2014

June 4, 2014

J'ai eu des propositions sur différents sujets que je préfère soumettre, dans ce qui suit je présente ce qui est en place et ce qui est proposé puis mon avis. Pour la synchro: Ce qui est présent : à chaque création d'un temps ou d'une tâche, on la pousse vers le serveur puis si une modification est faite on change l'élément en base. Si l'élément n'a pas pu être poussé il est stocké puis la tentative est faite plus tard. Avantage: pas de doublon, "petite" base Désavantage: perte des données de départ au profit des modifications Ce qui est proposé: avoir un système un peu comme des log qui va pousser un temps toutes les 5 min tant que le chrono est actif. pour les modifications il est alors ajouté un temps négatif. Avantage: tout est sauvegardé Inconvénient : volumétrie de la base, perte d'information sur le moment de la modification(début ou fin de période). Mon avis: Les deux solutions sont équivalentes, le risque de perte des données est faible. Cependant la seconde solution peut rapidement devenir trop volumineuse. Pour le fonctionnement de l'application: Ce qu'on a: L'UI est supposée fonctionner sans le module du serveur. L'UI stocke les données dans son local storage puis envoie les données vers le serveur qui stocke les données dans la base. Avantage: possibilité de fonctionner sans une connexion. Inconvénient: taille du local storage limité Proposition : Livré l'UI packagée avec un serveur pour permettre de se passer du local Storage et utiliser directement les données du serveur. Petit plus: utilisation des websockets pour prévenir l'UI. Avantage: pas de duplication des données (local Storage/base), Désaventage: plus lourd Mon avis: Je pense qu'il est probable que le localStorage ne puisse pas accueillir suffisamment de données. Il peut être intéressant d'utiliser la seconde idée.

2 1