Ce topic est réservé pour toutes les questions concernant le langage de programmation web, le PHP.

J'ai des tables sql représentées dans des modèles PHP (classe) et je souhaite pouvoir développer un outil qui faire un sort de tagging entre mes modèles. En fait, je dois pouvoir lié tout type de modèles entre eux, avec un seul et même système, avec une gestion par rang des données pour chaque "tagging". Comment faire ?

En somme c'est un système relationnel généraliste.

C'est du troll ou tu essaies vraiment de faire ça ? xP (ou les 2 =D), parce que là c'est une drôle de coïncidence.

Nan mais si je dis ça c'est parce que le framework dont je parlais il y a quelques temps avec le système media-description, et bah ils sont justement en train d'élaborer la nouvelle version qui va vraiment vers ce que tu demandes, c'est à dire au lieu de créer des medias dans une table, d'attribuer un type ainsi que les dépendances etc, et bah on crée des tables et des champs. C'est une autre façon de voir les choses mais c'est en somme très correct).

Bon TALC mais j'ai quand même envie de donner mon idée; je ne sais pas si il existe des requêtes SQL permettant de sélectionner le nom d'une table (donc pas son contenu mais bien la table elle même), ainsi que ses champs (et proprietés) mais j'aurai pensé par exemple à structurer le tout en XML, XML qu'on pourra parser par la suite pour restructurer l'ensemble (puisque comme tu le dis; on ne connaît pas le nom des tables, ni des champs, ni quoique se soit). Le truc c'est de trouver le moyen de stocker ces infos là quelques part pour pouvoir par après, par exemple dans le backoffice reconstituer l'ensemble). Ou alors mais là c'est aussi un peu tordu; séparer le boulot en 2 bases de données; une qui servira à stocker l'ensemble des informations, et l'autre bah la base de données telle que l'utilisateur/développeur la créera.

Fin c'est ce qui me passe par la tête, faut faire le tri bien entendu mais disons que le principal problème est comme tu dis: comment gérer automatiquement quelque chose qui n'existe pas encore mais qui doit l'être une fois créé.

Pour les droits, si je me souviens bien ils utilisent un système de modules lié à une table keyring (des portes-clés quoi) avec bien entendu une relation 1 à n (un module pouvant appartenir à plusieurs groupes (membres, admins, modérateurs, rédacteurs, webmasters bref tout ce que tu peux imaginer). Bref pour le cas des tables je ne sais pas si pour toi ça peut fonctionner.

C'est du demi-troll. La conception est intéressante à faire.

Par contre, ce n'est pas ce que tu décris dans ton premier paragraphe. On garde complétement les système de tables classique : une table = un type de données (Voiture, Personne, etc). Au boulot on a un ORM pour travailler (symfony pour le framwork, propel pour l'orm), conclusion, quand je décide de faire une table Voiture (décrit dans un fichier de conf yml ou xml), une (plusieurs en fait) classe est générée et permet de modéliser par de l'objet cette table : c'est basiquement le rôle d'un ORM.

Pour un projet, mais ça a été utilisé dans d'autres, on a eu besoin d'avoir un outil pour lier plein de données entre elle sans maitriser au départ leur type. En effet, entre deux projet, on aura de nouvelle tables et donc de nouvelles classes et ça parait débile de développer un outil trop spécifique et non réutilisable.

J'ai donc développer un widget (et un slot) Symfony pour faire ça. On décrit dans un fichier de configuration les classes qui identifie un modèle taggable. On lui assigne au passage un titre (la classe "Car" a comme titre "Voiture" par exemple). Ensuite, on a pensé une table permettant de faire du relationnel 1:1 entre un tag et un objet (c'est le tagging). On a deux type de tag : les tag visibles ("informatique", "coup de gueule", "pour de lol") et les tags invisibles (ma_class_id_element). Quand un objet est taggé, on est capable de savoir tout les objets en relation avec lui via les tagging (et les tag en commun). J'ai également typé le tag tagging pour gérer des niveaux relationnels : ainsi, si A et lié à B niveau 1, alors B est lié à A niveau 1, mais si on ne souhaite pas connaitre le lien de A vers B (dans ce sens) car on affiche les données (par exemple), on tag dans un autre niveau. Exemple : on a un menu qui peut faire pointer des liens vers n'importe quel élément de la base de données. Pour ce faire, on utilise le système de tag avec le niveau "menu", ainsi, si on affiche la donné lié à l'élement de menu et qu'on souhaite afficher l'ensemble des élements liés, on va définir de ne pas afficher les tag de niveau "menu" (osef de savoir que Foo est lié à un node de menu).

Un des sites ouvre demain donc je montrerai en live, mais par exemple, dans une de nos fiches spectacles, on a lié des éléments affichés sous cette forme : http://upload.deblan.fr/u/2011-09/4e6683bd.png . En backoffice, on a ça : http://upload.deblan.fr/u/2011-09/4e66845c.png

Content de voir que pour une fois je n'ai pas eu une idée à la con. xP

En fait comme dit, j'ai commencé à bouloter sur cette idée il y a 2-3 mois après avoir discuté avec mon prof et utilisé un framework qui est totalement basé sur cette idée, mais avec directement avec le système de creation de table mais l'idée globale était la même, la nouvelle version en cours de développement se base vraiment cette fois ci sur ce système là, question de plus de flexibilité (même si je trouve que l'ancienne logique en possédait déja pas mal, cependant c'est vrai que ce n'était peut être pas très sémantique pour certains). Bref si les débuts ont été un peu rudes (c'est dur de passer d'une logique simple à la "site du zéro", à un truc où tout est abstrait et où tu doit prendre en compte toutes les demandes potentielles, sans savoir finalement ce que le site contiendra), mais finalement morceau après morceau le bazar s'assemble tout doucement et commence à rouler (ce sont mes premières classes aussi xP). Je n'ai pas encore fini la bête mais de même si tu as envie un peu de tester par la suite, pas de soucis.

Pour les dépendances (ou relations etc), disons que je fonctionne aussi avec une configuration (la news sera par exemple l'enfant d'une catégorie, mais tout comme un sous menu est l'enfant d'un menu, et en même temps le parent d'un sous sous menu lui même parent d'un sous sous sous menu, bref exemple à la con mais c'est pour montrer qu'une fois le concept établi, on lie à peu près tout comme on veux, et quelque soit la relation (1-1, 1-n etc). Certes ça demande un peu plus de ressources ça je ne peux pas le nier, mais question boulot bonjour l'économie (là je pense que tu seras d'accord sur ce point xP) !

Quand tu veux pour le live. xP