Je suis d'accord avec toi sur le point suivant : il est difficile de tout réorganiser sans perdre les informations propres à PWG associées aux photos.

Je ne suis pas d'accord avec toi sur le point suivant : dissocier complètement l'arbre des catégories de l'arborescence des répertoires. En effet, lorsqu'on arrive à penser cela, c'est qu'on a déjà franchit pas mal d'étapes de réflexion sur l'organisation de sa galerie. Or, ceci serait intéressant pour 5% des utilisateurs de PWG (et je serai dedans...).

Cela dit, ce que tu souhaites faire est déjà possible en branche 1.4 grâce aux catégories virtuelles. Ergonomiquement, la gestion des liens entre photos et catégories est pourrie (je suis le premier à le dire), d'ailleurs, la branche 1.5 sera bien meilleure pour cela. Je conseille la lecture du billet Panier et gestion par lot sur mon blog.

La page sur la gestion des catégories dans le wiki fournit déjà quelques conseils.

Actuellement, PWG laisse l'administrateur très libre de ses choix d'organisation. C'est un choix conceptuel.

Sur ma galerie personnelle, j'utilise une version de la branche de développement qui permet déjà la gestion par lot et mon arborescence de répertoire n'a rien à voir avec l'organisation finale visible de mes catégories : je peux facilement organiser et réorganiser. Mon arborescence de répertoire ressemble à

.
`-- chrono
    `-- 2005
        |-- 01-january
        |-- 02-february
        |-- 03-march
        |-- 04-april
        |-- 05-may
        |-- 06-june
        `-- 07-july
            |-- 20050727.1
            |-- 20050728.1
            |-- 20050728.2
            |-- 20050730.1
            |-- 20050731.1
            |-- 20050731.2
            `-- 20050731.3

Sur le mois de juillet, j'ai commencé à gérer mes photos avec la notion de "photoset" (exemple : 20050728.2). Un photoset est un ensemble de photos regroupé de manière logique et indiscutable dans le temps. Par exemple 20050727.1 correspond aux photos de mon fils à la maternité le 3ème jour (dans 10 ans, je n'aurai aucune raison de réorganiser cela). Un photoset est nommé de la façon suivante : <date de la première photo YYYYMMDD>.<numéro incrémental du jour>. Un photoset peut contenir des photos sur plusieurs jours et même sur 2 mois différents (ce que ma précédente organisation ne permettait pas).

Il faudrait que je fasse un billet sur mon blog pour expliquer tout cela (l'expérience me -//:---\spam que l'organisation des photos numériques n'est pas une chose simple si on veut faire quelque chose de pérenne).

afchsn a écrit:

Et si au lieu de classer les photos a priori dans une arborescence selon la logique de l'administrateur, ce qui peut devenir ingérable , on les enregistrait dans un seul répertoire physique (galleries)!!! [reste de l'explication très intéressante]

En théorie, bien sûr qu'il est possible de mettre toutes tes images dans le même répertoire. En pratique, je ne le conseille pas, pour plusieurs raisons :

- lorsque tu auras 5000 photos, il faut savoir que tous les filesystem ne vont pas avoir un niveau de performances optimal. Il faut découper. A 5000 photos, la synchronisation risque d'être un peu longue et indécoupable :-/ Si tu as déjà eu l'occasion d'être hébergé chez free, tu auras peut-être remarqué que le répertoire racine de ton compte utilisateur n'est pas /home/afchsn mais plutôt /home/a/f/c/afchsn, la reprise des 3 premières lettres permet de découper pour limiter le nombre de sous-noeuds.

- pour l'archivage/backup. Personnellement, l'arborescence sur mon site web (avec les photos au format web 640*480) est la même que mon répertoire de photos en local (avec les photos au format original 3000*2300). Je sauvegarde régulièrement mon répertoire de photos et le tout dépasse largement les 650Mb d'un CD-R. Si j'avais toutes mes photos dans un répertoire unique, la sauvegarde serait plus compliquée à gérer car le répertoire serait obsolete à chaque photo ajoutée. Avec des répertoires dont le contenu ne peut pas changer au cours du temps (ce que je propose dans mon précédent post), une fois n'importe quel répertoire sauvegardé, le CD-R ne deviendra jamais obsolete.

- parce que la gestion des associations photos/catégories (virtuelles) est ergonomiquement pourrie en branche avant la future branche 1.5 (voir plus bas dans ce post).

Le système que tu proposes (catégories à partir des paramètres de tri) est strictement identique à la section "Réutilisation des recherches" de la spécification pour l'évolution du moteur de recherche en branche 1.5 (dont le développement a été reporté à la branche 1.6, faute de temps). Même si tu l'exprimes un peu différemment, je pense que nos idées se rejoignent. Je t'encourage vivement à faire part de tes remarques dans le topic dédié.

afchsn a écrit:

J'avais cru comprendre que les catégories virtuelles répondaient (en partie pour l'instant puisque seul l'Admin en décide) à ce type de logique, mais je n'arrive pas à trouver comment il faut faire. Comme d'autres l'ont noté, au passif, mais c'est souvent le problème de brillants concepteurs, ils ont du mal à rédiger des modes d'emploi suffisamment détaillés et explicites pour les utilisateurs qui en sont réduits à deviner voire à abandonner faute de compréhension.

Je compati, c'est chiant de détailler et de rédiger  quand on a passé des heures à le concevoir, et qu'on la les neurones en effervescence sur les versions à venir,  mais c'est tellement plus commode pour l'utilisateur....

En fait, si je n'explique pas encore très bien comment utiliser les catégories virtuelles, c'est parce qu'ergonomiquement, c'est pourri avant la branche 1.5. Personnellement, j'utilise massivement les catégories virtuelles uniquement depuis que j'ai développé le traitement par lot associé au panier (fonctionnalités branche 1.5)

Bon, en dehors de ça, rédiger la documentation, ça me gonfle un peu, de toute évidence. C'est d'ailleurs pour cela que j'ai choisi un système de wiki : pour que les autres fassent la doc à ma place :-) Mais la mayonnaise ne prend pas tellement, il faudrait que je rédige davantage d'articles de base.

afchsn a écrit:

Petite remarque de l'expérience : on passe beaucoup moins de temps à rédiger un mode d'emploi complet qu'à répondre au fil de l'eau de façon décousue à l'avalanche des questions sur un forum doublé d'un blog personnel non officiel : On n'appellerait pas çà l'usine à gaz ??? -(;o))))

(Je vais répondre ce soir à ton commentaire sur mon blog)

Je suis d'accord avec toi : il faut privilégier la documentation quand elle existe et éviter de répéter 24 fois la même réponse à la même question. C'est d'ailleurs pour cela que j'ai écris des règles pour ce forum et que sur mon blog, j'ai parlé des canaux de communication autour du projet. Mais comme il ne s'agit que de mon blog, tout ce qu'il y a de plus officieux, il faudrait que je fasse un article dans le wiki... à moins que tu souhaites le faire ;-) (ça qui me ferait plaisir)

afchsn a écrit:

Dommage car le look de phpwebgallery ainsi que ses autres fonctionnalités le démarque nettement de la concurrence.

Et pourquoi tu n'as pas encore ouvert un topic dans la section testimonials and show off (remerciements) pour expliquer tout ce qui t'as fait choisir (ou te fait t'intéresser à) PhpWebGallery ? (ce qui me ferait très plaisir)

afchsn a écrit sur mon blog (alors que cela n'avait rien à y faire, on ne poursuit pas une discussion sur 1 topic du forum puis sur mon blog...)

afchsn a écrit:

J'ai vu que peu d'intervenants sur les forums de pwg avaient l'usage (ou la compréhension) des catégories virtuelles telles que je les souhaiterais. A part les "spécialistes", peu de gens fonctionnent dans l'esprit base de données. Et l'on en revient aux "boîtes" physiques et à l'armoire de la grand-mère. J'ai géré des dizaine de milliers d'articles à titre professionnel et je sais de quoi je parle, alors 5000 photos, c'est peanuts.

Allez, je vais surenchérir, puisque (même si ça n'a aucun rapport) cela semble être important... A mon boulot, une des problématique à laquelle je dois répondre, c'est "comment migrer des bases de données de plusieurs centaines de Giga Octets dans une fenêtre de temps limitée", en gros des tables avec plus de 100 millions d'enregistrements... et je sais de quoi je parle, alors 5000 photos, c'est peanuts.

Sérieusement, en relisant bien mon post, j'ai bien parlé de 5000 fichiers dans un répertoire unique pour dire que la plupart des filesystems actuels ne sont pas optimisés pour cela. Mon argument reste valable.

Dans l'absolu, pour PhpWebGallery, gérer 5000 photos, c'est pas vraiment un problème, je te rassure.

afchsn a écrit:

Je trouve dommage de limiter l'usage de la BDD à l'administration. On peut avoir simultanément des requêtes fixes (catégories virtuelles définie par l'administrateur) et une requête paramétrable par l'utilisateur au choix.... Dans 2 ans peut-être, à moins que je m'y investisses.

Mais euh, les "recherches sauvegardées" ne te semblent pas toutes indiquées ? Elles sont prévues pour la branche 1.6 qui arrivera avant dans 2 ans.

afchsn a écrit:

Je ne partage pas du tout ton argument relatif à la capacité de sauvegarde limitée CD par CD. C'est fallacieux de justifier un mode de traitement sous prétexte de vouloir se limiter à un mode de sauvegarde lui même limité alors que la technique permet d'autres solutions.

Quand ton volume d'info augmente, tu mets tout simplement les moyens nécessaires à sa gestion et à sa sauvegarde. un second disque dur en mirroir ou même traité manuellement répond parfaitement à ce besoin sans couter aujourd'hui la peau des fesses. Tu peux même en faire un backup ponctuellement sur autant de CD qu'il en faudra. L'avantage d'un site payant est aussi de disposer chez lui d'une sauvegarde. Perso, j'ai aussi une image complète de mon site sur mon ordi avec CDs ailleurs.

Certes, avoir ses photos sauvegardé sur un second disque est une bonne solution, peu coûteuse. Mais si tu as grave problème électrique sur ton installation et que ça détruit ton ordinateur (et tous les disques) et bien, tu seras content de n'avoir fait de sauvegarde que sur les disques... La sauvegarde sur CD est une solution simple, économique et accessible au particulier. Entre parenthèses, ce qui prend de la place se sont les vraies photos, pas celles présentes sur un site web normalement (parce que si tu mets tes photos originales sur internet, ça doit peser bien lourd...)

afchsn a écrit:

Il faut bien évidemment disposer d'une sauvegarde dans un autre lieu que celui de l'ordinateur et c'est valable aussi bien pour les petits systèmes amateurs que pour les gros professionnels. Combien d'utilisateurs de pwg ont un sustème de sauvegarde organisé et fiable ????

Très peu, je te l'accorde :-) Je rappelle tout de même qu'il ne s'agissait que d'un argument, et je l'ai mis en deuxième car il est beaucoup moins important que le premier.

afchsn a écrit:

Mais même si on utilise des CD, il y a des logiciels de backup qui appellent les cd automatiquement à la file quand la capacité unitaire est insuffisante. Ghost fait çà très bien.

Oui, c'est vrai, mais je te décris comment je fais : je remplis mon arborescence chronologique (présentée plus haut dans le topic), dès que la somme des répertoire atteint 650MB, je grave le CD1 et je remet le compteur à 0. Ensuite, je ne compte que les nouveaux répertoires et dès que la somme atteint 650MB, gravure du C2. Et ainsi de suite.

De cette façon, le répertoire 2005/07-july/20050727.1 n'est présent que sur un seul CD. Je duplique éventuellement les CDs pour davantage de sécurité.

Bon, cette histoire de sauvegarde me semble suffisamment traitée et sans grand rapport en réalité avec ce topic. Je propose de nous concentrer sur les intéressantes informations qui suivent.

afchsn a écrit:

Le terme même d'arborescence implique une hiérarchie. Or les faits de la vie de tous les jours montrent des relations transversales que l'arborescence est tout à fait impropre à gérer.

Je ne suis pas certain de comprendre ce que tu dis. Je vais supposer que tu parles d'un système de tag. J'ai rédigé un billet sur mon blog comparant la classification d'éléments par catégories (impliquant hierarchie) et par tags : Système de tags. Ce qui est intéressant c'est d'explorer un ensemble d'éléments dont le nombre d'éléments se réduit à mesure que l'on rajoute des tags (ou des règles car un tag est une règle simple), on commence avec vacances, puis vacances+mer, puis vacances+mer+erwann et au final, tu visionnes les photos d'Erwann [1] en vacances à la mer.

[1] mon fils, qui ne va pas encore à la mer :-)

Ma conclusion est qu'implémenter un système de tag, et plus particulièrement un nuage de tags (voir des exemples sur Blogmarks, sur l'étonnant Flickr, sur O'Reilly radar ou encore le module Perl HTML::TagCloud de Leon Brocard) et bien ça m'intéresse (pour le challenge technique essentiellement) :-)

Bon, peut-être que ta phrase n'avait rien à voir, je ne sais pas :-?

afchsn a écrit:

Avec la table pwg_images correctement structurée, on peut créer autant de catégories virtuelles qu'on le souhaite puisque ce ne sont en réalité que des requêtes. On élimine complètement le souci de savoir si les caractéristiques d'une catégorie physique vont suivre ou pas lors du transfert suite à un changement d'avis sur le lieu de rangement initial.

En effet, les catégories virtuelles, c'est puissant parce que c'est souple. Une petite rectification peut-être : les catégories virtuelles sont statiques. C'est l'administrateur qui associe des photos à une catégorie. La catégorie virtuelle présente les mêmes photos tant que l'administrateur n'en décide autrement.

C'est là que se distinguent les "recherches sauvegardées". Par exemple, en tant qu'utilisateur, je fais une recherche sur l'auteur "pierrick" avec comme mot clef "marion" (les photos dont un des sujets est Marion), j'ai donc les photos de Marion prises par Pierrick. Je sauvegarde cette recherche et je peux la réafficher quand je veux. Avec une telle recherche, le contenu est susceptible de changer à chaque ajout de photos.

Les "recherches sauvegardées" pourraient s'enrichir (en spécification, avant le développement qui n'aura lieu que d'ici Noël je pense) de la possibilité à l'administrateur de considérer certaines recherches comme catégories spéciales, et ainsi être affichées dans le groupe dédiée du menu, de façon complètement transparente. Ce serait de la configuration très avancée, mais ça pourrait être sympa :-)

afchsn a écrit:

J'ai peut-être été excessif en proposant un seul répertoire. Finalement en jouant pour la visualisation des images que sur les catégories virtuelles, on se fout complètement de savoir dans quel fichier physique les clichés sont rangés. C'est la machine qui fait la relation.

Tomberions nous d'accord ?

afchsn a écrit:

[...] Les BDD relationnelles ont précisément été étudiées pour n'avoir qu'un fichier physique et le visualiser sous de multiples angles [...]

Oui, on tourne toujours autour de la même idée : les catégories virtuelles, c'est bien. Plus précisément, les liens virtuels entre photos et catégories (physique ou virtuelle), c'est bien.

Alors, certes, en branche 1.4, les liens virtuels ne sont pas simple à mettre en place à grande échelle car l'ergonomie est foireuse. Je promet qu'en 1.5, c'est largement mieux (et je l'utilise tous les jours).