[Centralisation] JCaddie

[aurielle]

  windu.2b a dit :

Pour les périodes des produits de saison, j'ai repéré certains sites indiquant ce genre d'informations, mais si d'autres se la sentent de compléter cela, j'accepte volontiers

Et pour les légumes dont tu parles, non je ne les ai pas ajoutés, mais le catalogue étant totalement personnalisable, libre à chacun ensuite d'y rajouter ce qu'il veut.

Quel format as tu besoin et comment? Lorinc m'a conseillé le xml, que je n'ai jamais pratiqué pour l"instant. Actuellement, je travaille sur du .odt. J'en suis à mars pour l'instant. c'est pas évident de confronter les différentes sources d'infos...Y a plus de saisons mon bon monsieur

[windu.2b]

  aurielle a dit :

  windu.2b a dit :

Pour les périodes des produits de saison, j'ai repéré certains sites indiquant ce genre d'informations, mais si d'autres se la sentent de compléter cela, j'accepte volontiers

Et pour les légumes dont tu parles, non je ne les ai pas ajoutés, mais le catalogue étant totalement personnalisable, libre à chacun ensuite d'y rajouter ce qu'il veut.

Quel format as tu besoin et comment? Lorinc m'a conseillé le xml, que je n'ai jamais pratiqué pour l"instant. Actuellement, je travaille sur du .odt. J'en suis à mars pour l'instant. c'est pas évident de confronter les différentes sources d'infos...Y a plus de saisons mon bon monsieur

A qui le dites-vous, ma bonne dame ? Tout part à vélo

Bon, plus sérieusement... Pour le format, l'idéal serait... le SQL

Comme ça, y a plus qu'à exécuter pour que ça insère dans la base de données

Mais vu que je n'ai pas encore bien réfléchi à la structure des tables et champs nécessaires pour stocker les tags et plus précisément ce genre d'informations, j'aurais du mal à te demander d'utiliser une structure dont moi-même j'ignore l'existence

Donc, continue en ODT si tu veux, y a pas de souci (au pire, j'irai mettre les mains dans le XML de l'ODT... Je sens que je vais aimer ça ).

Edit : mais si tu as un début de liste, je serais intéressé pour y jeter un coup d'oeil

[windu.2b]

A propos des périodes pour les fruits & légumes, j'ai trouvé ces 2 tableaux, mais j'y vois quand même pas mal d'incohérences

Aurielle, si tu peux nous en dire plus...

[aurielle]

  windu.2b a dit :

A propos des périodes pour les fruits & légumes, j'ai trouvé ces 2 tableaux, mais j'y vois quand même pas mal d'incohérences

Aurielle, si tu peux nous en dire plus...

Je préfère celui des courses pour la planète.

voici le début du mien je voulais te l'envoyer sur jabber ou par mail, mais ça fait longtemps que je ne t'ai pas vu sur le premier et je n'ai pas le deuxième. Demain soir, si tu le souhaites j'ajouterais d'autres mois. Je viens de démarrer une semaine très bof et fatiguante professionnellement, donc je vais faire ce que je peux. Par contre, n'hésites pas à m'indiquer comment faire pour te simplifier la tache. sachant que sortie du html: le reste je ne connais pas du tout.

[kran]

  windu.2b a dit :

  kran a dit :

Je viens de penser a une fonction qui pourrait etre interressante. Peut-etre y as-tu deja songé, mais dans le doute...

La fonction serait de garder toutes les modifications de la base sur le PC sur lequel on se synchronise, de telles manieres a avoir l'evolution du prix des divers produits dans le temps.

L'historique des prix est une chose qui existe déjà dans JCaddie.

En fait, c'est même déjà en partie implémenté : le prix que l'on voit est toujours le dernier prix valable (chaque prix a une date de début et éventuellement une date de fin).

Il reste cependant des choses à faire à ce niveau : gérer le cas où 2 périodes de prix d'un même produit se chevauchent (cas qui risque de se produire lors de synchronisation). Dans ce cas, il faudra laisser l'utilisateur choisir et/ou proposer une solution automatisée.

option > parametre > manuel/auto

et mettre auto par defaut

mais si je vois pas trop où (non pas la) tu veux en venir

[windu.2b]

  kran a dit :

  windu.2b a dit :

  kran a dit :

Je viens de penser a une fonction qui pourrait etre interressante. Peut-etre y as-tu deja songé, mais dans le doute...

La fonction serait de garder toutes les modifications de la base sur le PC sur lequel on se synchronise, de telles manieres a avoir l'evolution du prix des divers produits dans le temps.

L'historique des prix est une chose qui existe déjà dans JCaddie.

En fait, c'est même déjà en partie implémenté : le prix que l'on voit est toujours le dernier prix valable (chaque prix a une date de début et éventuellement une date de fin).

Il reste cependant des choses à faire à ce niveau : gérer le cas où 2 périodes de prix d'un même produit se chevauchent (cas qui risque de se produire lors de synchronisation). Dans ce cas, il faudra laisser l'utilisateur choisir et/ou proposer une solution automatisée.

option > parametre > manuel/auto

et mettre auto par defaut

mais si je vois pas trop où (non pas la) tu veux en venir

En fait, ma principale crainte avec l'idée de la synchronisation, c'est le risque que les données ne correspondent pas.

Exemple tout con mais qui va forcément se produire : imaginons que l'utilisateur A ajoute un produit X dans son catalogue. Il désire ensuite se synchroniser et mettre ainsi ce produit à disposition des autres. Oui mais...

Oui mais ce produit X a un identifiant, qui risque d'entrer en collision avec l'identifiant d'un produit Y créé par un utilisateur B qui aura synchronisé auparavant.

Bref, ce n'est pas simple... car si je dois changer les identifiants des produits de l'utilisateur A (celui qui se sera synchronisé en dernier), il faut aussi appliquer ce changement dans toutes les relations qui lient le produit X avec d'autres informations (prix, magasins, tags...).

Ou alors, il me faut trouver une méthode infaillible pour définir les identifiants, les garantissant uniques...

[lorinc]

un id unique pour chaque produit ? la date à laquelle le produit à été entré dans la base, style 20080528153057, soit le 28 mai 2008 à 15:30 et 57 secondes... si tu entres le même produit une deuxième fois, ce sera à une aute date, forcement...

[windu.2b]

  lorinc a dit :

un id unique pour chaque produit ? la date à laquelle le produit à été entré dans la base, style 20080528153057, soit le 28 mai 2008 à 15:30 et 57 secondes... si tu entres le même produit une deuxième fois, ce sera à une aute date, forcement...

Et si 2 personnes ajoutent un produit, chacune de leur coté, auu même moment ?

[theocrite]

Alors tu mets une table de hashage incrémentale

Ou alors tu rajoutes un id à la suite de la date

(Bon je ne sais pas faire du java alors en pseudocode)

id=0
while true
 si def date 'YYYYMMDDHHMMSS'.id
 id++
done

Ou sinon un simpe primary key uniq autoincrement.

[lorinc]

ou bien tu lui concatènela désignation du produit.

[windu.2b]

  theocrite a dit :

Alors tu mets une table de hashage incrémentale

Ou alors tu rajoutes un id à la suite de la date

(Bon je ne sais pas faire du java alors en pseudocode)

id=0
while true
 si def date 'YYYYMMDDHHMMSS'.id
 id++
done

Ou sinon un simpe primary key uniq autoincrement.

L'autoincrement est la solution actuelle, mais est la pire solution car elle en fait rien pour empêcher le cas dont je parle (la nouvelle valeur est choisie en fonction des produits existants dans la base locale)

  lorinc a dit :

ou bien tu lui concatènela désignation du produit.

je risque en effet de devoir faire un truc comme ça : tenir compte des caractéristiques du produit.

[theocrite]

  windu.2b a dit :

L'autoincremetn est la solution actuelle, mais est la pire solution car elle en fait rien pour empêcher le cas dont je parle (la nouvelle veleur est choisir en fcontion des produits existants dans la base locale)

Avoue, tu n'étais pas à jeun ?

[windu.2b]

  theocrite a dit :

  windu.2b a dit :

L'autoincremetn est la solution actuelle, mais est la pire solution car elle en fait rien pour empêcher le cas dont je parle (la nouvelle veleur est choisir en fcontion des produits existants dans la base locale)

Avoue, tu n'étais pas à jeun ?

Je ne vois pas de quoi tu parles...

Plus sérieusement, j'ai une put*** de dyslexie du clavier, ça fait parfois peur!

Edit : oulaaaah... Je les avais pas toutes vues, en fait !

[aurielle]

windu, je n'ai pas continué hier, ni ce soir, car je ne savais pas si ça allait comme cela ou si c'était inutile pour toi.

Si ça te va, je reprendrais ce week end. Dis moi assez vite (j'ai laissé tous les bouquins sur le sujet grands ouverts sur le bureau....il n'y a plus de place pour travailler dessus du coup)

[windu.2b]

  aurielle a dit :

windu, je n'ai pas continué hier, ni ce soir, car je ne savais pas si ça allait comme cela ou si c'était inutile pour toi.

Si ça te va, je reprendrais ce week end. Dis moi assez vite (j'ai laissé tous les bouquins sur le sujet grands ouverts sur le bureau....il n'y a plus de place pour travailler dessus du coup)

Je suis occupé tout le WE (mon père se marie ce soir, et je suis rentré tout spécialement en Corse, donc pas trop la tête à tout ça ).

Mais quand je rentre sur Caen (demain soir), je regarde tout ça plus attentivement, et on en discute si tu veux

[windu.2b]

@aurielle : bon, je me remets à la tâche, et je serais curieux de voir à quoi ressemble ta liste de produits et périodes de disponibilité, afin de réfléchir un peu à tout ça

[windu.2b]

Déterrage de topic pour me rappeler à vos bon souvenirs

Bon, j'ai pas bossé des masses cet été (doux euphémisme) mais là je m'y remets. Je monte d'ailleurs en ce moment un wiki pour me faciliter la centralisation des informations.

Par contre, j'aimerais savoir si quelqu'un ici connait un peu SyncML ? Je pensais utiliser ce protocole pour permettre de synchroniser les données du catalogue de produits, vers et depuis un serveur centralisateur.

Mais pour ça, j'ai besoin de savoir si ce protocole est "facilement" extensible ? Car j'ai cherché un peu d'informations à ce sujet, et je ne trouve rien (ce qui ne signifie pas forcément que j'ai mal cherché )

[aurielle]

J'ai gardé mes tickets de caisse pour créer mes prix/kg des aliments personnalisés...va pas falloir que je tarde trop

[windu.2b]

Bon, l'été étant passé, je viens (depuis 2-3 semaines) de m'y remettre

Y a-t-il des connaisseurs de l'UML et des diagrammes de classes qui pourraient me dire ce qu'ils pensent de ces 2 diagrammes ?

Le 2° fait appel au Design Pattern "Decorator", pour ceux à qui ça parle

Edit : bon, ça a pas l'air de vouloir charger les images...

Je remets les liens ici et là

[ouragan]

pour le jar sous windows :

dans une console :

java -jar \cheminvers\nom_du_produit

et on a les erreurs en sortie.

pour tes MLD , ben euh, ya trop de classes.

En fait le chemin normal c'est :

- CDC

- cas d'utilisation ( référencie toutes les actions que fait l'utilisateur )

- MCD ( uniquement les entités qui dialoguent avec ton programme = les tables que tu veux, les relations entre les tables, etc... )

- MLD tiré du MCD

- -> ton logiciel te sort avec ça les scripts SQL permettant de créer les tables utilisées.

Là faudra voir les scénarios possibles ( en français ) exemple :

l'utilisatrice clique sur un bouton, qu'est ce qu'il se passe ?

Pis des maquettes IHM.

Donc ce qu'il nous faudrait, là, c'est le cahier des charges , comment dire, bien ficelé déjà.

Pour ton logiciel je vois 5 ou 6 packages :

- 1 Controleur

- 1 IHM ( ou 2 si PDA != Desktop )

- 1 Persistance ( 1 classe par BDD + 1 classe connexion + quelques classes SQLException )

- 1 Metier ( intègre 1 classe par cas d'utilisation )

- 1 Synchronisation

- 1 SortieNonStandard ( pour gérer l'écriture vers PDF, ODT, etc... )

- 1 Historique ( pour gérer les historiques de prix et les statistiques persos )

L'idéal, issu du XP, serait d'avoir un logiciel qui fonctionne avec le minimum de fonction ( 3 boutons, pas de BDD , quelques méthodes ) et qui fonctionnera tout aussi bien à chaque fois que tu implémentes une nouvelle méthode/ BDD.

Les "cas d'utilisation, MCD" vont définir l'architecture des packages métier et Persistance.

Je connais très peu de choses de Merise, mais déjà, ces points de départ, c'est ce qui va te permettre d'avoir un programme facile à faire grossir. et à débugguer.

L'architecture va être créée avant d'écrire le moindre bout de code.

Chaque méthode créée se fait dans les classes qui sont dans les packages existants.

A chaque fois que tu implémentes une méthode, tu débuggues et tu ressors un exécutable fonctionnel.

Tu vas voir, le temps va te paraître beaucoup moins long.

[Quarky]

Big

Alors windu pas de news ?

Trouvé ceci qui pourrait t'être utile : Calendrier des fruits et légumes

[windu.2b]

  Quarky a dit :

Big

Alors windu pas de news ?

Trouvé ceci qui pourrait t'être utile : Calendrier des fruits et légumes

ben j'avance tout doucement, mais j'avance

En ce moment, je tente de finir toute la gestion de la base de données

[aurielle]

des nouvelles??? J'aurais beaucoup aimé utiliser jcaddie...

[windu.2b]

  Le 09/03/2011 à 20:22, aurielle a dit :

des nouvelles??? J'aurais beaucoup aimé utiliser jcaddie...

Euh... Disons que je considère JCaddie comme mort !

Mais si tu tiens à récupérer les sources, je dois pouvoir te les transmettre...

[aurielle]

J'aimerais beaucoup :)