Plusieurs arborescences pour le manager (et le frontend)

Bonjour,

j’aimerai pouvoir définir une arboresence en faisant intervenir les TVs.
Un exemple simpliste :
TVyear->TVkeyword->TVtype.

Ainsi les documents de l’année 2006 serait regroupés, puis divisés suivant le mot clef associé (par exemple php ou javascript), puis divisés suivant le type du document (tutoriel, exemple de code, erreur courante, lien web).
Cela permettrait au niveau du manager de rechercher plus facilement des documents si notre site ne suit pas cette arboresence.
On pourrait presque imaginer un site sans arborescence (même si ce n’est pas ce que je souhaite) et définir des arborescences uniquement avec les TVs.

Deuxième exemple un peu moins simpliste :
TVtype(personne->TVemploi;;document->TVkeyword(**)).
La TVtype peut prendre les valeurs "personne" ou "document", si c’est une personne on ventile suivant TVemploi, si c’est un document on ventile suivant TVkeyword et dans ce cas on reprend l’arborescence classique à partir de ces documents (c’est le role du **).

Ces arborescences pourrait être associées à certains rédacteurs, ou alors avoir des tests conditionnels en fonction du rédacteur (vérifier la valeur d’une TV).
On pourrait également les utiliser dans le frontend en spécifiant au tout début si nous voulons l’arborescence classique ou une autre. Cela serait utilisé par les WayFinder, PrevNextSibblings et autres DropMenu.

Bonjour,

Oui, peut être, mais où sont ces foutus aspirines ...

Désolé mais je ne vois pas bien le concept là.
Pour ton exemple je vois pas comment un document de type tutoriel concernant le php peut se retrouver dans une autre arborescence.
Au mieux tu peux afficher une arborescence de tous les tutoriaux mais tu supprimes la notion de TVkeywords.

La page de recherche de l’admin est peut être un peu juste ont pourrait rajouter un champ de recherche dans les TV et peut etre une période de création ce qui permettrait d’afficher tout les doc de l’année 2006 avec un terme trouvé dans les TV’s.

Sinon pour le deuxième exemple j’arrive pas à retrouver cette boite ....

Selon moi cela revient à présenter les contenus selon un mode proche des smarts lists d’iTunes.
Cela offre la possibilité de présenter le contenu selon une hiérarchie "physique" repertoire>document ou bien sur la base de metadonnées.
C’est un concept intéressant que j’ai essayé de mettre en pratique pour une banque d’images.
Je souhaitais pouvoir organiser les images selon une structure hierarchique mais les afficher selon leur metadonnées. De cette façon on évitait les doublons puisque si un album est définié selon une serie de mots clés stockées dans les documents images, ceux ci pouvaient aisément appartenir à plusieurs albums sans être récréés.
Toutefois je n’y suis pas parvenu, ditto n’offrant pas de performances de tris satisfaisantes pour ce type de présentation.

:-)

Je pense qu’héliotrope a déjà éclairci mon post un peu confus mais je vais revenir sur mon premier exemple.

Imaginons que la véritable arborescence du site soit : deux répertoires "php" et "javascript", puis dans php on crée une fiche par fonction (par exemple asort()). Pour chacune de ces fiches on peut créer un document-fils de type tutoriel par exemple, ou encore "exemple" ou bien "erreur fréquente". En ce cas nous n’avons pas une vision claire de tous les tutoriels crées. On peut bien sûr faire un appel à Ditto dans le frontend pour voir tous les tutoriels, mais pour les modifier nous devons les rechercher dans l’arborescence.
D’où l’intérêt à mon avis de spécifier des nouvelles "user-arborescences".

Un mot sur Ditto si j’ai bien compris son utilisation. Ditto ne gère pas d’arborescence, et pour séparer les tutoriels sur javascript et php nous devons faire deux appels à Ditto. Le but ici est bien de créer une nouvelle arborescence.

Juste un mot sur le deuxième exemple même s’il n’est pas essentiel. Dans le premier exemple on ventile suivant une suite de TVs mais sans prendre en compte les valeurs précédemment choisies. Ainsi pour la TVtype, si l’on a choisi "article", il y a peu de chance pour que l’on s’intéresse ensuite à la TVyearborn, alors qu’elle serait intéressante si l’on avait choisi "personne".
Cela est quand même secondaire par rapport à la prise en charge du premier exemple.

Les TVs sont un des éléments de différenciation de modx face à ces concurrents.
Mais on peut regretter le manque de fonctionnalités qui leur sont rattachées.
Par exemple l’absence des TVs dans les résultats de recherche.
Ou encore l’impossibilité de lier deux TVs pour créer des listes conditionnels.
Bien sur tout cela doit être mesuré à la relative précocité du produit.

Pour en revenir à ta proposition je crois pour ma part que c’est une partie du manager qui doit être revu.
dès lors que l’on a un contenu conséquent, il montre ses limites.
De même si on peut saluer l’apparition de catégories pour les chunks snippets etc... je ne crois pas avoir vu la possibilité de lister tous les éléments (quelque soit leur type) pour une catégorie sélectionnée.

:-)

Quote from: heliotrope at Oct 03, 2006, 11:42 AM

Les TVs sont un des éléments de différenciation de modx face à ces concurrents. Mais on peut regretter le manque de fonctionnalités qui leur sont rattachées. Par exemple l’absence des TVs dans les résultats de recherche. Ou encore l’impossibilité de lier deux TVs pour créer des listes conditionnels. Bien sur tout cela doit être mesuré à la relative précocité du produit.

100% d’accord avec toi, sur tous les points.

La bonne nouvelle, c’est qu’étant donné l’ouverture de nos devs préférés, il faut impérativement poster ça dans la Wishlist voire proposer ça dans les forums de dev. J’ai vu que tu travaillai sur un module, c’est déjà un super début.

En tout cas, tu peux être sûr qu’aucune bonne suggestion ne sera perdue ici, c’est la grande force du projet à mon avis
Et si tu lances quelque chose de concret, la meute de codeurs fous furieux va pousser derrière

Quote from: heliotrope

Pour en revenir à ta proposition je crois pour ma part que c’est une partie du manager qui doit être revu.
dès lors que l’on a un contenu conséquent, il montre ses limites. De même si on peut saluer l’apparition de catégories pour les chunks snippets etc... je ne crois pas avoir vu la possibilité de lister tous les éléments (quelque soit leur type) pour une catégorie sélectionnée.

Non pas encore... soumettre l’idée à Kyle qui a eu l’idée et développé ça, ce serait une bonne chose
Je ne serai pas étonné que ça n’attende pas plus longtemps que la prochaine release pour être mis en oeuvre

Re

De même si on peut saluer l’apparition de catégories pour les chunks snippets etc... je ne crois pas avoir vu la possibilité de lister tous les éléments (quelque soit leur type) pour une catégorie sélectionnée.

Dans le dernier onglet : "Toutes les ressources" , tu as la liste de tous les éléments quelque soit leur type classé par catégorie. Tu ne peux pas selectionner une catégorie mais bon il y a déjà ça.

Je viens de découvrir votre discussion et l’idée principale rejoint ce que je cherche à faire pour une galerie d’images. Mais ça pourrait servir aussi à autre chose que des images.
Si j’ai bien compris le premier message de ce thread, il s’agit de faire ce que font les dossiers intelligents sous os X et que devait faire vista avec les dossiers virtuels. Je crois bien que zfs le fait aussi et le premier à avoir fait ça était bfs de Beos, très en avance sur son temps. Techniquement il s’agit de gérer fichiers et dossiers directement à travers la base de données.

Concrêtement, on fait une recherche sur des métadonnées. On stoke le résultat dans un dossier virtuel et lorsqu’un nouveau fichier correspondant à la recherche est ajouté au système il est automatiquement ajouté (mais ce n’est pas une copie) au dossier virtuel, qui se met à jour tout seul. En fait ça remet en cause le principe d’arborescence des fichiers. Le système de fichiers est considéré comme une base de données. Bonnard.

Au départ je pensais que pour avoir une telle fonctionnalité dans un cms, ModX au hasard, il fallait disposer d’un os qui gère ces dossiers virtuels. Or effectivement, on pourrait peut être contourner ça directement depuis le cms.

Un des avantages, est de pouvoir ensuite générer des dossiers virtuels depuis des recherches. Ce qui me parait encore plus intéressant serait de pouvoir le faire depuis des caractéristiques (métadonnées) qui sont déjà dans les fichiers de part son format, donc indépendament de l’os. Je reprends mon exemple d’images:

Si on doit entrer des métadonnées pour chaque image quand on les ajoute à ModX afin de pouvoir les classer automatiquement dans le(s) (multiples) dossiers virtuel(s), c’est déjà bien, mais c’est pas le top. Parce que ces métadonnées seraient propres à ModX. Et du coup ça imposerait une indexation in situ si je puis dire.
Or si on peut indexer dans ModX en utilisant des métadonnées déjà présente dans tout .jpg par exemple, un simple déplacement depuis je ne sais où jusqu’au serveur qui héberge ModX conduirait directement à la mise à jour des dossiers. Avec un classement automatique à la clé. Voilà qui me semble très attractif.

Je sais que vista (qui finalement ne le proposera pas paraît il) prévoyait de faire ça un utilisant du xml pour gérer ce genre de dossier. Pour les autres systèmes, je crois que c’est une surcouche chez osx. Et chez bfs c’était directement la base de données qui répondait, ce qui est l’idéal. Donc tout n’était que requètes à une base de données. C’était vraiment très performant.

Pour revenir à ModX, je ne sais pas sous quelle forme ceci pourrait être implémenté, mais l’essentiel, la base de données, est déjà là. Les développeurs doivent savoir comment faire mieux que moi. Mais ça me paraîtrait vraiment très utile.