🌍
Français
[Évolution] => Voyons si cela a un sens et si c'est réalisable....
Après il faut faire une demande d'évolution pour qu'une future release intègre la fonctionnalité, sinon lettre morte.
8-)
J'ai pas tout compris... :(
Avez vous reussis? Est ce possible?
Exact.
VDigital a écrit:
mathiasm a écrit:
Mais où les affiche-t-on?
En-dessous du bloc de miniatures, après la nav bar du bas? Ça fonctionne quelque soit le type, et même en mode calendrier.+1
Un seul (le dernier en date) avec un lien vers la recherche de commentaires correspondante.
Mais à ce propos, la catégorie sera représentée par sa miniature mais la Galerie?
Donc le dernier commentaire avec un lien de type "more...", si je comprends bien ?
Pour représenter la galerie, soit une miniature à choisir, soit le logo PWG, qui serait à inclure dans la distrib.
mathiasm a écrit:
z0rglub a écrit:
#comments.related_type enum('image', 'category', 'gallery', 'tag', 'year', 'month', 'day')
#comments.related_id int
C'est pas si sale.+1.
Mais où les affiche-t-on?
En-dessous du bloc de miniatures, après la nav bar du bas? Ça fonctionne quelque soit le type, et même en mode calendrier.
+1
Un seul (le dernier en date) avec un lien vers la recherche de commentaires correspondante.
Mais à ce propos, la catégorie sera représentée par sa miniature mais la Galerie?
z0rglub a écrit:
#comments.related_type enum('image', 'category', 'gallery', 'tag', 'year', 'month', 'day')
#comments.related_id int
C'est pas si sale.
+1.
Mais où les affiche-t-on?
En-dessous du bloc de miniatures, après la nav bar du bas? Ça fonctionne quelque soit le type, et même en mode calendrier.
z0rglub a écrit:
Ah non, ça c'est vraiment pas bien du tout. Tant qu'un commentaire n'est pas lié à plus d'un "objet", il ne faut pas créer de table dédié pour créer une relation autre que N-N.
Tout à fait, c'est avoir du N-N, c'est juste un proposition... une présentation, ... bref des exemples de ce qu'il possible.
D'ailleurs, dans ton 1er exemple (image_id, cat_id), ca permet d'avoir un relation 1-2 (1 commentaire pour 2 types)
z0rglub a écrit:
#comments.related_type enum('image', 'category', 'gallery', 'tag', 'year', 'month', 'day')
#comments.related_id int
C'est pas si sale.
Et j'aime plutôt bien! Ca permet d'être générique.
En plus pour reprendre un de tes derniers posts, avoir un id numérique pour chaque type est toujours.
rub a écrit:
Une autre solution, c'est de créer des tables de liens entre #comment et les images ou les catégories.
C'est à dire, rajouter les tables (comment_id, image_id), (comment_id, cat_id).
Ca permet la d'avoir (aussi) le même commentaire pour les images ou les catégories.
Ah non, ça c'est vraiment pas bien du tout. Tant qu'un commentaire n'est pas lié à plus d'un "objet", il ne faut pas créer de table dédié pour créer une relation autre que N-N.
#comments.related_type enum('image', 'category', 'gallery', 'tag', 'year', 'month', 'day')
#comments.related_id int
C'est pas si sale.
z0rglub a écrit:
Bof... je n'aime pas trop car on déstructure l'information. Mais en contrepartie, on est effectivement nettement plus souple. A-t-on seulement systématiquement des identifiants numériques (un mois ou un jour donnée par exemple ?).
Perso, 2 champs id, j'aime moyen mais c'est vrai (type, id) ca déstructure.
Une autre solution, c'est de créer des tables de liens entre #comment et les images ou les catégories.
C'est à dire, rajouter les tables (comment_id, image_id), (comment_id, cat_id).
Ca permet la d'avoir (aussi) le même commentaire pour les images ou les catégories.
z0rglub a écrit:
(dans PWG, element = image donc element_id ce n'est pas vraiment générique)
Oui, c'est vrai, parlons alors de object_id ou autre chose.
rub a écrit:
z0rglub a écrit:
table #comments mais au lieu de l'image_id, il faudrait remplir le category_id (nouvelle colonne), si ni l'un ni l'autre n'est rempli, c'estun commentaire global à la galerie. Bon en fait, c'est pas si compliqué pour le modèle de données...
Ou bien supprimer le champ image_id, le remplacer par les champ (type_id, element_id), ca permettrait de mettre des commentaires sur tout.
Bof... je n'aime pas trop car on déstructure l'information. Mais en contrepartie, on est effectivement nettement plus souple. A-t-on seulement systématiquement des identifiants numériques (un mois ou un jour donnée par exemple ?).
(dans PWG, element = image donc element_id ce n'est pas vraiment générique)
z0rglub a écrit:
table #comments mais au lieu de l'image_id, il faudrait remplir le category_id (nouvelle colonne), si ni l'un ni l'autre n'est rempli, c'estun commentaire global à la galerie. Bon en fait, c'est pas si compliqué pour le modèle de données...
Ou bien supprimer le champ image_id, le remplacer par les champ (type_id, element_id), ca permettrait de mettre des commentaires sur tout.
Voire même aussi pour la galerie complète.
Ma principale question, c'est au niveau du modèle de données : ce serait logique de réutiliser la table #comments mais au lieu de l'image_id, il faudrait remplir le category_id (nouvelle colonne), si ni l'un ni l'autre n'est rempli, c'estun commentaire global à la galerie. Bon en fait, c'est pas si compliqué pour le modèle de données...
Pour la présentation par contre... où afficher ces commentaires utilisateur ?
C'est une idée... Je change le titre de la discussion. 8-)
mathiasm a écrit:
par galerie, nous devons comprendre catégorie?
OUi OUi :)
par galerie, nous devons comprendre catégorie?