sur le wiki on a écrit:
Chaque site PWG peut naturellement utiliser le service “Disponible??? d’un autre site PWG qu’à la condition que son propre service soit “Disponible??? et qu’au moins une catégorie non vide soit définie comme une ressource accessible. (Extension ultérieure probable)
J'ai peur de comprendre que le "Service XML" d'un site PWG ne peut être appelé que depuis un autre site PWG... Je me trompe?
J'ai remarqué que les types de requêtes proposées pour le service XML ne retourne que des photos non contrôlées par l'adminsitrateur (random, plusVues, mieuxNotées,...). Peut-on envisager de proposer des listes construites : une catégorie (réelle ou virtuelle) ou une liste fixe.
L'idée est la suivante : j'ai mon site unique PWG dans lequel je stocke toutes mes photos (ma famille, mes amis, mes vacances, etc...). A coté de ça je souhaite faire un site qui traite d'un sujet bien spécifique (sur la naissance de mon p'tit ou sur la race de mon chien par exemple). Pour ne pas avoir à dupliquer mes photos sur les deux sites je souhaite pouvoir appler depuis mon site web une liste "bébé" ou "chien" prédéfinie dans mon site PWG.
MBt
Hors ligne
MBt a écrit:
J'ai peur de comprendre que le "Service XML" d'un site PWG ne peut être appelé que depuis un autre site PWG... Je me trompe?
Toute application pourra récuperer le flux, bien sûr (d'abord les blogs sont les premiers visés), mais tout browser supportant l'XML devrait pouvoir le flux et si j'arrive à faire ce que j'ai dans l'idée, il y aura les photos et pas seulement du texte avec au début une mise en page minimale mais...).
MBt a écrit:
J'ai remarqué que les types de requêtes proposées pour le service XML ne retourne que des photos non contrôlées par l'adminsitrateur (random, plusVues, mieuxNotées,...). Peut-on envisager de proposer des listes construites : une catégorie (réelle ou virtuelle) ou une liste fixe.
Non contrôlées, t'exagère un peu, j'ai mis trois niveaux de contrôle, et z0rglub n'en veut que deux pour l'instant.
Mais pas de problème pour les listes construites (j'ajoute l'idée dans le wiki, bien qu'il s'agit tout simplement d'une catégorie virtuelle cachée tout simplement)... Donc, cela rejoint parfaitement mes concepts.
Aujourd'hui, z0rglub veut la fonction et je suis d'accord. Mais j'essaierai d'intégrer la solution catégorie si le temps me le permet.
Hors ligne
VDigital a écrit:
Non contrôlées, t'exagère un peu
Excuse! Je ne parlais évidemment pas de "contrôle" au sens "sécurité/autorisations" mais au sens "j'envoie ce que je veux/vous recevez ce que je vous donne".
VDigital a écrit:
bien qu'il s'agit tout simplement d'une catégorie virtuelle cachée tout simplement
Je pensais aussi à une implémentation de ce genre (ouf! je suis bien en phase avec vous).
Hors ligne
Oups! (Ça dort ici, les idées sont en panne), up... Up.... UP... UP!.. UP!. UP! UP!! UP!!!
On se réveille.
Dans la table `#_categories`
la colonne `visible`, ENUM( 'true', 'false' ), NOT NULL, DEFAULT 'true'
ne représente pas sa visibilité mais son verrouillage.
Faut-il une vraie colonne `visible` comme le sous-entend ceci?
Ce qui permettrait de faire de l'upload sur cette catégorie sans pour autant,
voir les uploads validés apparaître dans Spéciales + Dernières images...
Alors?
Pourquoi c'est lié à services web? Effectivement, pas uniquement à cela, comme l'upload par exemple mais aussi la promotion.
Ce point aurait pu être dans le sujet [Evolution] Les catégories virtuelles c'est une section commune d'arbo différentes comme dirait rub. 8-)
Votre avis? (J'ai déjà lu quelque chose comme ça quelque part, ou j'ai révé?)
Hors ligne
VDigital a écrit:
z0rglub a écrit:
[Administration>Catégorie>Service web] permettra de créer le strict équivalent à $conf['XML_switch']. Imagines que pour les commentaires utilisateurs, il faille les autoriser dans [Administration>Configuration>Commentaires] puis autoriser les catégories dans [Administration>Catégories>Commentaires]. Ce serait pénible et inutile.
Bonne remarque: Justement, tiens je voudrais autoriser les commentaires, mais avoir une catégorie non comment"able"? Comment fais-je?
Tu vas dans [Administration>Catégories>Commentaires], tu rends toutes tes catégories commentables, sauf une.
vdigital a écrit:
z0rglub a écrit:
A la limite, en suivant ce raisonnement, $conf[’XML_service’] (via fichier) devient inutile. Sauf que tu estimes qu'il y a des administrateurs qui accèdent à l'interface d'administration de PWG sans pour autant pouvoir accéder au fichier de configuration. Dans ce cas, c'est sensé.
Quasiment jamais utilisé certes, mais censé et pratique.
Tu dis cela parce que tu trouves plus pratique de gérer le paramétrage via écran que via fichier à mon avis. Je préfèrerais que ce paramétrage ne soit pas en double si possible (et si tu tiens à le mettre par écran, vas-y, mais cela me semble innaproprié).
vdigital a écrit:
z0rglub a écrit:
Je trouve quand même dommage d'imaginer qu'il puisse être utile de désactiver le service web parce qu'on confie l'administration de sa galerie à une personne à laquelle on n'a pas confiance :-/ un comble. J'ajoute que ne sachant pas vraiment qui utilise le service, en désactivant, cela aura des conséquences sur un nombre inconnu de sites externes.
Je sais bien et tu as raison, mais je cherche aussi à nous protéger:
" Ne venez pas vous plaindre, vous aviez le moyen d'éviter l'affichage de ces images sur votre site même en votre absence. Vous êtes responsable de votre site en aucun cas l'équipe de PWG. "
Je ne suis absolument pas contre le fait de ne pas permettre l'utilisation de service par défaut. Pour moi, $conf['xml_service'] doit être à false par défaut. C'est du paramétrage avancé, seul une poigné en comprendra le sens profond et ne l'activera qu'en connaissance de cause (à bien commenter donc). C'est pour cela que je préfère le fichier de conf à l'écran, pour ce paramètre précis.
vdigital a écrit:
Dis-moi la différence en tu as un ticket valable et tu as une clé valable? Ok, on parle de clé, et je ne peux pas ne pas l'intégrer dès la 1.6
J'aimerais que tu nous rafraichisse la mémoire avec l'histoire des tickets. Je n'en ai pas vraiment souvenir et tu ne donnes pas de lien sur le sujet.
vdigital a écrit:
Je ne marche pas... z0rglub joue au poker menteur. Il a tout compris[...]
Oui, j'ai compris. Je fais un peu le bête pour mettre en évidence certains points. Notamment, je pense que c'est un dev compliqué pour un premier dev et je pense que tu veux en faire trop d'un coup. Je pense qu'il faut commencer par la simplicité.
vdigital a écrit:
1.6 de PWG: XML Service avec XML_Service en $Conf, agreed_xml_service au niveau des catégories et un tableau de 'service_key' en $conf.
pourquoi un tableau de clefs ? une seule ne suffit pas ?
vdigital a écrit:
1.7 ou + (ultérieurement): Les catégories partagées.
En triant mes photos du nouvel an, il y avait les miennes et celles envoyées par mon oncle. J'ai habilement suggéré à mon oncle de monter un site PWG, ce qu'il a accepté, et donc on le fera bientôt ensemble. Bref, pour mes photos du nouvel an, il est clair que j'aimerais afficher sur ma galerie les photos du nouvel an prise par mon oncle et qu'il affiche sur son site. Surtout que les photos de mon oncle sont largement meilleures que les miennes ! Donc, la fonctionnalité m'intéresse à titre personnel (et ça change tout ;-)
Hors ligne
MBt a écrit:
[...] Peut-on envisager de proposer des listes construites : une catégorie (réelle ou virtuelle) ou une liste fixe.
L'idée est la suivante : j'ai mon site unique PWG dans lequel je stocke toutes mes photos (ma famille, mes amis, mes vacances, etc...). A coté de ça je souhaite faire un site qui traite d'un sujet bien spécifique (sur la naissance de mon p'tit ou sur la race de mon chien par exemple). Pour ne pas avoir à dupliquer mes photos sur les deux sites je souhaite pouvoir appler depuis mon site web une liste "bébé" ou "chien" prédéfinie dans mon site PWG.
Evidemment, de base un service enverra les informations sur les images de la catégorie 134. Cette catégorie 134, (qui s'appelle en réalité [Gens>bébé]) elle peut-être virtuelle.
1. Tu te ballades dans ta galerie et tu mets dans le panier les photos en rapport avec le bébé.
2. Une fois ta sélection terminée, tu vas dans l'administration, gestion des catégories, tu rentres dans la catégorie [Gens], et tu créées une catégorie virtuelle [Gens>bébé].
3. Edites les propriétés de la nouvelle catégorie pour autoriser la consultation par service (n'existera qu'en 1.6 évidemment) car cette propriété sera désactivée par défaut (n'est-ce pas VDigital ?).
4. Ecran [Administration>Images>Panier], associe toutes les photos de ton panier à la nouvelle catégorie [Gens>bébé].
La nouvelle catégorie thématique est consultable via service, elle ne contient que les photos que tu as bien voulu y mettre.
Hors ligne
VDigital a écrit:
Dans la table `#_categories`
la colonne `visible`, ENUM( 'true', 'false' ), NOT NULL, DEFAULT 'true'
ne représente pas sa visibilité mais son verrouillage.
En effet, la terminologie a changé au fil des années. Pour faire propre, il faudrait renomme la colonne en "locked".
vdigital a écrit:
Faut-il une vraie colonne `visible` comme le sous-entend ceci?
Ce qui permettrait de faire de l'upload sur cette catégorie sans pour autant,
voir les uploads validés apparaître dans Spéciales + Dernières images...
Je ne vais pas discuter ici de l'intérêt des catégories cachées dans le cas général. Mais dans le contexte de la consultation des catégories par service, pourquoi voudrait-on ne pouvoir consulter une catégorie que via service ? (je fais un blocage là-dessus, de toute évidence)
Hors ligne
z0rglub a écrit:
Je ne vais pas discuter ici de l'intérêt des catégories cachées dans le cas général. Mais dans le contexte de la consultation des catégories par service, pourquoi voudrait-on ne pouvoir consulter une catégorie que via service ? (je fais un blocage là-dessus, de toute évidence)
Dans une catégorie virtuelle masquée, je prépare des sélections d'images lesquelles sont affichées et disponibles dans la galerie, et uniquement dans la galerie.
Je ne veux pas afficher dans la galerie mes catégories masquées (sélections préparées) pour XML Service, elles "déstructureraient" ma galerie.
Les fonctions futures auront besoin de catégories spécifiques n'altérant pas l'organisation de la galerie, et auront toujours besoin comme xml_service de catégories réellement ignorées du reste de l'appli (sauf de l'admin bien entendu).
Hors ligne
z0rglub a écrit:
Imaginons une galerie perso, l'admin ne souhaite pas que n'importe qui puisse afficher ses photos perso de manière incontrôlée. Ne devrait-on pas donner la possibilité de ne questionner le service qu'avec une clef ? du type $conf['service_key'] = 'TS9VqM73'; et cette clef ferait parti des paramètres de l'URL de requête au service. Ainsi, je suis sûr que seul mon blog sera capable d'utiliser le service de ma galerie. Il y a peut-être une idée à creuser, non ?
Je reviens sur cette belle idée sans être certain de la développer immédiatement dès la 1.6, quoique c'est facile...
A ce jour, j'imagine plus une seule clé mais deux clés.
$conf['service_key'] = 'TS9VqM73';
ou
$conf['service_key'] = array("current" => "TS9VqM73", "next" => "0li0NdOr");
La seconde technique permet de synchroniser un changement de code avec les utilisateurs du service.
Parce que la clé pourrait être divulguée et utilisée par des personnes non autorisées...
Le webmaster communique uniquement à ses "partenaires" la clé "next" à changer avant la fin du mois,
et donc ils ne subissent pas d'interruption du service.
Le premier jour du mois suivant, il bascule ainsi:
$conf['service_key'] = array("current" => "0li0NdOr", "next" => "RS9HaK66");
Et uniquement ceux qui n'ont pas la nouvelle clé, sont à terre.
Ça ne coute pas cher, facile à réaliser.
Est-ce clair? Est-ce que ça vaut le coup?
(Une idée bête en relisant les posts).
Alors ma question: J'en mets deux ou une seule?
Hors ligne
lol, j't'en colle trois, ok. C'est toi qui explique... d'accord?
Hors ligne
Si tu veux faire un truc aussi compliqué (pourquoi pas), je propose plus générique :
$conf['service_keys'] = array( array( 'id' => 'TS9VqM73', 'start' => '2006-01-23 21:38:00', // this key has a beginning and a end 'end' => '2006-01-25 23:50:41', // date, a period a validity ), array( 'id' => '0li0NdOr', 'start' => '2006-01-24 00:00:00', // this key only has a beginning date of validity ), array( 'id' => 'pfQ091xb', 'end' => '2006-12-31 23:59:59', // this key only has a end date of validity ), );
Alors oui, c'est un poil plus complexe, mais c'est plus marrant à faire au niveau du code et cela s'adaptera à beaucoup plus de situations certainement.
Hors ligne
C'est pas le tout, mais faudra le vendre...
$conf['service_keys'] = array( array( 'id' => 'TS9VqM73', 'end' => '2006-07-25 23:50:41', // this key is invalid later that timestamp (Failure) ), array( 'id' => '0li0NdOr', 'end' => '2007-01-18 00:00:00', // this key is authorized after that validity date ), array( 'id' => 'pfQ091xb', // this key is valid ( no check ) ), );
Je donne la première à nicolas, la seconde à z0rglub, et la troisième pour mon blog...
Le 'start' est éliminé, il suffit de ne pas donner la clé.
Si count($conf['service_keys'])==0 alors pas de contrôle de clé.
C'est plus simple.
Adjugé, à moins qu'une idée moins tordue mais tout aussi efficace ne germe de vos esprits.
Hors ligne
VDigital a écrit:
Le 'start' est éliminé, il suffit de ne pas donner la clé.
Ouais... enfin, ça ne te coûte rien de la garder. Tu ne sais pas encore toutes les utilisations possibles. Des gens utiliseront tes idées bien au-delà de ce que tu imaginais au départ. Tu fais comme tu le sens, mais c'est une économie bien inutile.
Hors ligne