rvelices a écrit:

Au sujet des permissions: Si j'ai le lien A=>B, et je n'ai pas la permission de voir A, alors je suppose qu'en regardant B, les photos de A ne vont pas apparaitre. Correct?

A n'en pas douter.

rvelices a écrit:

Personellement j'aurai un tres fort interet pour ce dev si on peut gerer pas seulement les elements directement composant la source, mais aussi recursivement les elements des categories filles de la source. Par exemple: je defini le lien A+recursif=>B, alors en B ca me -//:---\spam les elements de B + tous les elements de A et les fils de A. Le but est aussi de pouvoir faire A+recursif=>A par exemple. Au niveau de la table il suffit de rajouter une colonne, mais est-ce qu'il sera difficile de gerer ca ? En fait c'est quelque chose de ce genre qui m'a manque au tout debut quand j'ai choisi d'utiliser pwg.

Avec une petite galerie, cela reste compréhensible.
Avec certaines:
1-cela peut "bouffer" de la CPU...
2-rendre le résultat incompréhensible par le webmaster lui-même.



Avec "récursivité" qu'il faudrait appeler peut être "exploration/développement":

A -> (est parente de) B
A -> B -> C, D
E -> F -> G, H

C = (contient les images) (1, 2, 3, 7)
D = (11, 13)
G = (11, 12, 16)
H = (2, 3, 4)
A,B,D,E,F = ( ) = vident d'images


G => (est source de) D                                soit D= (11, 13, et 12(G), 16(G))
H => C                                                       soit C = (1, 2, 3, 7 et la 4(H))
A => H       
soit   H = (2, 3, 4, et 1(C), 7(C) et 11(D), 13(D) et 12(D(G)), 16(D(G))) 
et C = (1, 2, 3, 7 et la 4(H) et 11(H(D)), 13(H(D)) et 12(H(D(G))), 16(H(D(G))))

Moralité:
H : (affiche) (1, 2, 3, 7, 11, 12, 13, 16)
C : la même chose

Résultat:  Question du user lambda "Pourquoi j'ai la même chose? Il est bien évident que si je voulais faire des catégories identiques, je serai un peu dérangé, je n'ai jamais voulu cela !!! expliquez-moi... ou j'y comprends rien, je laisse tomber".

Ma réponse:
Pas de "récursivité" ou d' "exploration/développement"
Et je ne parle pas de casser H => C...

Bon, je vois que vous portez de l'intérêt à cette fonctionnalité. Mais je pense que vous en attendez trop, en tout cas davantage que la spécification initialement écrite. Je commence par encourager ceux qui ne l'ont pas encore fait, à lire le topic 5245. Je redonnes ici une liste de principes associés à cette fonctionnalité de liens source/destination :

- les liens source/destination entre catégories (stockés dans #categories_link) permettent de générer des liens image/categorie (dans #image_category). Il faut voir les liens source/destination comme une méthode d'alimentation.

- les liens image/category n'ont pas d'origine traçable. C'est à dire qu'a posteriori, je ne peux pas savoir si l'association de la photo 1 à la catégorie C est issue d'une opération manuelle ou d'un lien source/destination entre la catégorie A et C. Si une photo est liée à la source et à sa destination, alors je suppose que l'association à la destination vient du lien source/destination.

- la gestion des permissions est liée aux catégories. Les liens source/destination n'ont absolument aucune influence sur les permissions.

- les photos d'une catégorie sont un sur-ensemble de l'union des ensemble des photos de ses sources. Une destination est forcément liée à au moins autant de photos que l'ensemble de ses sources.

- lors de la suppression d'un lien source/destination, suppression des liens image/categorie qu'on suppose issus du lien.

Je tiens à noter que cette fonctionnalité va largement au-delà de mon besoin initial, puisque celui-ci était surtout ergonomique... puis j'ai voulu ajouter la notion de persistance, et là tout se complique.

mathiasm a écrit:

z0rglub a écrit:

Je tiens à noter que cette fonctionnalité va largement au-delà de mon besoin initial, puisque celui-ci était surtout ergonomique... puis j'ai voulu ajouter la notion de persistance, et là tout se complique.

Par persistance, tu entends [...]

Par persistance, j'entends le fait que si j'ai déclaré A source de C, alors ultérieurement, toute association d'image à A entraîne la création d'une association d'image à C.

Mon besoin initial était juste de pouvoir créer une catégorie virtuelle dans l'écran de gestion de la catégorie physique, avec création des liens image/catégorie entre les photos de la catégorie physique et la catégorie nouvelle virtuelle. Comme mes catégories physiques sont évenementielles, une fois remplies, elles ne sont plus jamais mise à jour. Donc je n'ai pas besoin de persistance personnellement. D'où le fait que j'ai déjà élevé le niveau d'exigences, là j'ai peur que vous ne le surrélevier ;-)

mathiasm a écrit:

mets en oeuvre selon ta version, ce sera la première marche... Si ça passe en 1.6, les evol° passeront en version mineure.

De préférence non. Les évolutions fonctionnelles ne sont autorisées que sur la branche de développement, les branches stables sont dédiées à la stabilisation, donc à la correction de bugs bloquant et peu impactant.

mathiasm a écrit:

Ta persistance est la bienvenue dès lors qu'on veut une catégorie tous les xxx:
cas simple:
- catégorie E avec toutes les photos d'Elodie.
- catégorie P avec toutes les photos de Pauline, sa soeur.
Si je veux une catégorie S avec toutes les photos des 2 soeurs, je la relie aux cat P et E et c'est tout bon

Je suis d'accord, les liens source/destination vont résoudre avec élégance ce genre de problèmatique.

mathiasm a écrit:

Autre ex.: une catégorie tous les Noëls, tous les anniv,etc

Là, je ne suis pas d'accord, c'est la classification par tag qui devrait être mise à profit en l'occurence.

J'ai l'impression que je ne vais jamais réussir à finir ce dev :-/ J'en suis à plus de 500 lignes de PHP assez complexes (manipulation de tableaux dans tous les sens). Alors que mon besoin initial se code en quelques lignes et que finalement je ne pense pas que la persistance et la possibilité d'avoir N sources et N destinations ait un intérêt : c'est bien trop complexe pour 99,9% des utilisateurs. Je pense aussi à la maintenabilité :-/

Bref, je vais commiter bientôt, mais je sens que je vais revenir à mon besoin initial qui s'obtient en quelques lignes. Le code sera de toute façon dans le gestionnaire de version...

Dans [Subversion] r1064, il y a un bug a priori dans 10-database.php => Pas de prefix_table ...

Sinon, un petit retour:
A mon avis tu t'es trop pris la tête pour la gestion de l'admin:
Supprime le bloc "Create a destination category", qui ne sert à rien (création de cat virtuelle).
Tu fais un bloc "Alimentation de catégories" (Category fill/feed?) dans lequel tu insères les 2 autres blocs avec les doubles select.
Je pense que c'est plus un problème de nommage qui rend ça troublant.
Au lieu de source/destination, j'aurai plutot vu une notion d'incorporation de contenu:
Ce qu'on fait, c'est bien incorporer (intégrer, rattacher, relier?) le contenu d'une catégorie à celui d'une autre ?

mathiasm a écrit:

Dans [Subversion] r1064, il y a un bug a priori dans 10-database.php => Pas de prefix_table ...

Voilà, c'est corrigé dans [Subversion] r1065.

mathiasm a écrit:

A mon avis tu t'es trop pris la tête pour la gestion de l'admin:
Supprime le bloc "Create a destination category", qui ne sert à rien (création de cat virtuelle).

C'est marrant, parce que c'est uniquement ça mon besoin initial. C'est vraiment le seul intérêt que je vois personnellement à cette fonctionnalité : pouvoir créer un catégorie virtuelle à laquelle j'associe toutes les photos de ma catégorie physique courante.

mathiasm a écrit:

Je pense que c'est plus un problème de nommage qui rend ça troublant.
Au lieu de source/destination, j'aurai plutot vu une notion d'incorporation de contenu:
Ce qu'on fait, c'est bien incorporer (intégrer, rattacher, relier?) le contenu d'une catégorie à celui d'une autre ?

Non, car il y a plusieurs façon d'alimenter des catégories : liens ajoutés manuellement, ajout par FTP. Personnellement, ce n'est pas la terminologie qui me trouble :-) mais la montagne de code associée.

rvelices a écrit:

Si t'as deja passe du temps dessus, pourquoi l'enlever ?

Parce que le besoin de départ était simple et que ça s'est transformé en un code complexe qui sera difficile à maintenir pour aboutir à une fonctionnalité intéressante, mais franchement pas très utile (je parle de la persistance). Les possibilités qu'elle permet sont disponibles via d'autres fonctionnalités.

Peut-être que j'ai mal conçu le code en l'occurence, mais c'est merdique. Il faut savoir reconnaître quand on a fait une erreur, cette fonctionnalité est une erreur.

rvelices a écrit:

Ca a l'air de tres bien marcher.

Non, ça marche de manière bancale pour le moment, dans le [Subversion] r1065 que je viens de commiter, j'ai rajouté le support des associations/dissociations manuelles ultérieures à la création du lien source/destination.

rvelices a écrit:

(la seule choese: je n'ai pas bien compris pourquoi storage_category_id est passe dans l'autre table... ca rend d'autres requetes plus complexes et ce n'est pas tres "conception BD relationnelle" ... ).

Cela faisait longtemps que je souhaitais déplacer #images.storage_category_id dans #image_category.is_storage et c'était l'occasion. Cela ne rend pas les requêtes spécialement compliquées (en tout cas aucune requête de la partie publique n'est changée) à mon avis et ça simplifie le code à plusieurs endroits. Je ne comprends pas la remarque sur la conception relationnelle de la BD :-/

Bref... je veux bien qu'on s'amuse un peu avec la persistance des liens source/destination en BSF, mais je souhaite retirer tout ça avant la branche 1.6.

rvelices a écrit:

Une image a toujours une et une seule categorie comme storage, d'ou naturellement le "storage category" est un attribut de l'image. En le mettant dans image_category -> on peut avoir potentiellement plusieurs categories avec is_storage=true pour la meme image ou on peut ne pas avoir du tout une storage category pour une image. Mais ce n'est pas grave ... je trouvais juste plus naturel le model precedent.

Je comprends mieux la remarque. (edit, texte de cette parenthèse à retirer: A mon avis, c'est très subjectif :-) puisque je vais te répondre qu'une contrainte d'unicité sur #image_category.{image_id, category_id, is_storage} est tout à fait équivalent, et qu'il faut que je la rajoute :-)) Tu as raison, ma modification est incohérente. Faut que je réfléchisse aux avantages/inconvénients. Je souhaite éviter les redondances dans la base et les possibilités de désynchronisation.

rvelices a écrit:

Si tu veux le retirer pour la 1.6 pas de pb.

Moi je dis qu'on se donne 2 à 3 semaines pour regarder à l'utilisation, mais qu'on prévoit de supprimer #categories_link (et pas #image_category.is_storage, qui n'a pas de rapport direct avec la fonctionnalité dont nous discutons dans ce topic)

Dernière modification par z0rglub (2006-03-06 14:51:50)