🌍
Français
Continuons le besoin de discuter par là.
8-)
acp,
Si tu as d'autres questions liées à ton besoin, tu peux reprendre ici...
8-)
VDigital a écrit:
J
Il faudrait qu'on "discute" sur les règles à respecter, ne crois-tu pas?
A mon avis, il faut plus qu'on donne un petit exemple dans le WIKI de comment créer une table pour jointure et un exemple de requête avec jointure.
Cette façon de s'y prendre m'avait traversé l'esprit, mais pour une raison qui m'échappe encore, j'ai quelques choses contre les 'JOIN'. Ceci dit, l'avantage est que du coup, revenir en arrière est encore plus simple et plus rassurant pour l'utilisateur final.
Je suis d'accord avec toi, z0rglub.
Une nuance, tout de même, c'est que tout le monde n'a pas la connaissance nécessaire pour concevoir une évolution de la structure de cette façon.
Il faudrait qu'on "discute" sur les règles à respecter, ne crois-tu pas?
8-)
Mon conseil : pour faire les choses vraiment proprement, rien de tel qu'une table séparée qui serait lié à #sites par jointure. La table spécifique au module doit au moins contenir un champ site_id (norme de nommage dans PhpWebGallery).
Concernant #images.path, c'est un champ "calculé". C'est à dire qu'à tout moment, on peut supprimer sa valeur et la recalculer par lecture dans #sites.galleries_url, #categories.dir et #categories.uppercat_id et #images.file. Donc, il ne faut pas y toucher, c'est une espèce de cache.
acp a écrit:
Hmmm intéressant ça. Un petit avant-goût de ce qui est prévu, enfin comment vous comptez faciliter l'intégration des modules ?
C'est un peu premature car toujours en cours de dev et pas encore finalise
acp a écrit:
Hmmm intéressant ça. Un petit avant-goût de ce qui est prévu, enfin comment vous comptez faciliter l'intégration des modules ?
Indice https://mail.gna.org/listinfo/phpwebgallery-cvs
et http://svn.gna.org/viewcvs/phpwebgallery/
Si tu descends la version trunc, tu auras un aperçu dans admin, il ya un nouveau menu mais je ne dirais pas plus.
Hmmm intéressant ça. Un petit avant-goût de ce qui est prévu, enfin comment vous comptez faciliter l'intégration des modules ?
Je pense que modifier le path n'est pas une solution viable a terme (on l'utilise pour pas mal des choses).
De toute maniere dans la version 1.7 il y aura quelques modifications dans pwg pour faciliter l'integration des modules (secure images compris).
C'est en fait pour la gestion de site distants dans le module secureImages. Je croyais au début que je pouvais juste changer le champ "path" du fichier listing.xml (je remplace par http://hop.com/getRemoteFile.php?id=X) et que hop ça allait être bon. Mais la synchro ne marchait plus (en effet dirname sur http://hop.com/getRemoteFile.php?id=X et http://hop.com/categorie/souscategorie/image1.jpg, c'est pas pareil).
A la limite, je pensais ajouter un champ id_remote à la table d'images, puis un champ du style path_to_remote_getFile dans la table des sites distants (enfin des sites en général finalement, puisque ./galleries en fait partie). Ça devrait résoudre mes problèmes. Mais j'aurai préféré ne pas toucher à la BD.
acp a écrit:
Tant que j'y suis, est-ce que le champ "path" dans la table d'images pour les fichiers étant sur un site distant est très important (mis à part pour afficher l'image bien évidemment). Ce que je veux savoir c'est s'il est utilisé pour autre chose que juste l'affichage (par exemple, s'il est utilisé pour avoir des informations sur les répertoires qui contiennent l'image, etc.).
Merci
Le champ path est bien entendu utilisé pour l'affichage mais aussi pour les opérations de maintenance qui reconstituent justement le path de chaque image.
Il vaut mieux éviter toute modification.
Je ne comprends pas ce que tu voudrais en faire.
8-)
Le champ path est important pour plein des choses (c'est pour ca qu'il est la). Et il n'y a aucune garantie que on ne fera pas une utilisation supplementaire demain.
Peux-tu decrire ce que tu cherches faire exactement ?
En effet, la seule commande d'insertion que j'ai trouvé énumère les champs et valeurs qui doivent être ajoutés, donc à priori ça passe. Sinon, pour le reste des idées ? :)
acp a écrit:
INSERT INTO <tables des sites distants> VALUES (3, 'http://le.site.distant/');
Si je rajoute un champ supplémentaire, cette requête échoue normalement.
Si tu ajoutes une colonne, ça sera avec une default value, donc pas de pb. Non?
Tant que j'y suis, est-ce que le champ "path" dans la table d'images pour les fichiers étant sur un site distant est très important (mis à part pour afficher l'image bien évidemment). Ce que je veux savoir c'est s'il est utilisé pour autre chose que juste l'affichage (par exemple, s'il est utilisé pour avoir des informations sur les répertoires qui contiennent l'image, etc.).
Merci
