Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

vimages
2006-07-31 17:10:42

Tu as raison, mais je ne disait pas que ce n'est pas sérieux....  quand j'avais eu l'idée du mur d'image, je trouvais que ce serait une façon de présenter, et/ou de mettre à disposition sur des sites tiers, nos photos de façon inédite et originale.
En même temps, je voulais dire que certaines fonctionalités, telles que l'affichage par les tags ou la gestion des permission de voir ou pas les pwg_high étaient prioritaires..
Il y a les évolutions de fonctionnalités, d'ergonomie, de bases et les évolutions bonus.
Pour ma part, les évolutions de bases me permettent d'offrir un serveur photos fonctionnel, de qualité à mes clients (et à la famille :o) ) c'est vital. Le mur d'images sera un super bonus, témoin de la qualité et du dynamisme de PWG, de son team de dévelopeurs, il nous donnera encore une longueur d'avance, ce sera un motif de fierté.

voili voilà...

merci,
éric.

jillij
2006-07-31 16:44:15

Marrant comment suivant la facon de voir les choses, ca change tout.

Pour moi cette fonctionnalité c'est du très très serieux. Je pense que ca peut propulser phpwebgallery beaucoup plus loin en terme de nombres d'utilisateur.
Ca permet l'interfacage avec tous les autres logiciels libre disponibles:
forum, blog, calendrier, gestion de site...
J'en passe et des meilleures.

Mais c'est clair que c'est plus du coté developpeur qu'utilisateur.

vimages
2006-07-31 16:04:35

Je suis loin de l'avoir oublier... 8-)

je le sais bien !  :o)

mais pas de soucis, cette évolution inédite en bluffera plus d'un, mais en même temps, cela n'a rien de vital, certaines évolutions ou fonctionnalités ont une utilité indéniable, et sont une grande aide dans l'utilisation de PWG.
ici, c'est plus pour le fun, pour épater la galerie, il faut être honnète !

Je ne veux évidement pas de démobiliser, je vais me régaler de proposer ça à mes contacts!

merci encore !


amicalement,
éric.

jillij
2006-07-31 15:47:05

Une petite reamarque et des grands encouragements enthousiastes sur cette fonctionnalité:

Pour photon 4.0, en fait j'ai "émulé" un système de services web pour integrer dans le theme courant wordpress, les menus, les images, tout quoi.
Quelque fopen plus tard, tout est là (en fait j'utilise curl pour faire passer les cookies mais bon).
En couplant ça avec l'authentification via wordpress, on arrive à tout faire.

Pour ça je suis passé par un template default avec des balises pour indiquer où aller le code demandé.

Donc vous me voyez venir, un système de services web bien fait par défaut dans phpwebgallery me permettrait de faire tout ça sans avoir besoin
de "baliser" le theme (d'où en plus une installation encore plus facile).

Ca serait donc vraiment vraiment cool si vous l'implementiez dans le coeur de phpwebgallery.

Photon commence à grandir au niveau nombre d'utilisateur et je cherche la solution la plus propre possible et c'est clairement celle-là.

VDigital
2006-07-31 15:28:14

vimages a écrit:

et donc, on peut espèrer un peu plus tard, an "external picture wall" ... in english in the texte :o)

remember an old topic... about that..

Je suis loin de l'avoir oublier... 8-)

Pour ta pomme, je m'y collerai juste après même si j'ai fait déjà des essais.
Je pense que pour toi, je te ferai un petit MOD plus simple car tes images sont landscapes à 99.99%
Donc facile.
Pour une version plus généraliste, ce sera après.

8-)

vimages
2006-07-31 15:00:08

good news !!!

tout vient à point à qui sait attendre !

merci!!  :o)


et donc, on peut espèrer un peu plus tard, an "external picture wall" ... in english in the texte :o)

remember an old topic... about that..

pour que des visiteurs indentifiés puissent afficher un pavé de vignettes, style mur d'image, dont chaque vignette change comme un diaporama aléatoire..? genre 9 vignettes en 3x3...  et dont la source serait une catégorie privée, bien définie et à laquelle ce visiteur aurait les droits d'accés...?

future exclusivité PWG !!

affichez sur votre site web, sur votre bureau, un mur d'images en perpétuel mouvement !

(on est pas loin même si la conception technique est fondamentalement différente, du widget dont j'avais parlé..)

merci,
éric.

VDigital
2006-07-31 14:09:19

nicolas a écrit:

De quelle manière implémentes-tu ces services ? Pourra-t-on aisément exporter toutes les fonctions que l'on souhaite sous forme de services ? Je te donne un exemple pour être plus clair: est-ce que dans ton modèle il est envisageable de gérer les utilisateurs/groupes (ajout, suppression, mise à jour,...) sous forme de services ?

Pas dans cette version, dans les spécifs nous nous en tenions qu'à des requêtes sur les images.
Je n'ai pas imaginé l'aspect Administration.
Pourquoi pas?
Le moteur ne serait sans doute pas trop impacté, par contre pour répondre à ce besoin, il devrait s'appuyer sur d'autres tables et ce n'est pas prévu du fait que ceci n'était pas dans les spécifs de départ.

Quand je parle de bonnes surprises, c'est à propos du dernier besoin exprimé par z0rglub...
cat=7,9 (J'avais prévu ceci au départ).
ou
id=126,132,164,165,212,245,315,712,841,1045 (demande de z0rglub et de MBt de mémoire)
ou encore
tag=17,32,63 (Ça c'est la surprise).

Pour cette version, seules les images sous réserve qu'elles appartiennent à une catégorie publique pourront être obtenues.
Dans une version ultérieure, un groupe existant pourrait être associée à l'accès correspondant et de ce fait élargir le scope des résultats... Mais là encore, c'est hors scope du besoin initial.
8-)

nicolas
2006-07-31 13:46:37

De quelle manière implémentes-tu ces services ? Pourra-t-on aisément exporter toutes les fonctions que l'on souhaite sous forme de services ? Je te donne un exemple pour être plus clair: est-ce que dans ton modèle il est envisageable de gérer les utilisateurs/groupes (ajout, suppression, mise à jour,...) sous forme de services ?

flipflip
2006-07-31 13:37:04

Cool VDigital, j'attend avec impatience ton programme.

VDigital
2006-07-31 12:45:03

[Un petit point d'avancement ne ferait sans doute pas de mal...]

A savoir en résumé:

- Une table spécifique gère les services (conditions d'accès).
- La partie admin de cette table est quasiment terminé (il me reste trois/quatre modifs à faire dont une lourde).
- Le module de service doit quant à lui être réécrit pour se baser sur cette table.
- Et un petit exemple d'utilisation doit être revu pour montrer comment mettre en oeuvre.

D'ici une quinzaine de jours, je passe la main à z0rglub sur le bébé.
(Libre à lui d'apporter toutes les améliorations qu'il souhaitera voir.)
Quelques bonnes surprises sont à prévoir pour les amateurs d'idées nouvelles, mais aussi quelques problèmes sans doute (cf. les problèmes avec free que nous avons connus).

Uniquement compatible avec 1.6 (Le mode adviser est vivement recommandé pour l'assistance, les clés d'accès sont masquées à la personne qui est en ce mode).

Disponibilité prévisible: Début septembre.

8-)

nicolas
2006-07-26 09:35:35

flipflip a écrit:

Je relance le sujet pour savoir où en sont les travaux sur le sujet. Il y avait bien External Ramdon mais je ne le trouve pas dans le gestionnaire d'extension.

Je ne connais pas cette extension. Je ne sais pas précisément où en est Vincent.

flipflip
2006-07-26 08:49:43

Je relance le sujet pour savoir où en sont les travaux sur le sujet. Il y avait bien External Ramdon mais je ne le trouve pas dans le gestionnaire d'extension.

vimages
2006-04-02 14:48:48

A ce jour, la définition des accès se fait via le config_local.inc.php...
Imaginez qu'un autre site lance un include de votre config_local.inc.php,
Il obtient les clés d'interrogation prétendument confidentielles pour interroger votre site via services web.
Il n'a plus qu'à lancer les requêtes...

Donc, la gestion des droits va passer dans une table.
Et la gestion de cette table dans l'admin.
Voila pourquoi service web sera livré sous forme d'un MOD après les Releases Candidates de la 1.6.

très bonnes nouvelles !
merci !

VDigital
2006-04-02 10:29:51

Des nouvelles de services web.

Service web arrivera sous forme d'un MOD dans un premier temps.
Il tourne, et c'est même ce que j'utilise sur la page d'accueil de SOS MADAGASCAR.

A l'usage, j'ai compris que si je le livrais tel, j'ouvrai aussi la boîte de Pandore. J'explique:

A ce jour, la définition des accès se fait via le config_local.inc.php...
Imaginez qu'un autre site lance un include de votre config_local.inc.php,
Il obtient les clés d'interrogation prétendument confidentielles pour interroger votre site via services web.
Il n'a plus qu'à lancer les requêtes...

Donc, la gestion des droits va passer dans une table.
Et la gestion de cette table dans l'admin.
Voila pourquoi service web sera livré sous forme d'un MOD après les Releases Candidates de la 1.6.

VDigital
2006-02-06 07:43:04

Adopté: mais je ne sais pas si ce sera inclu ce soir...
(Je me doutais de ce type de demande).

L'inconvénient de ce type de demande est si le service est trop ouvert... L'aspiration totale des photos publique du site...
for ($i=1;$i<2000;$i+=5)
{
  $list='';
  for ($j=$i;$j>($i+5);$i++)
  {
     $list .= $j;
   }
  ?type=list&list=$list;
//  Exploitation
}

Grace au compteur d'images de la galerie, la limite (ici 2000) est connue.
Voila pourquoi j'ai expliqué dès le début à MBt (de mémoire) que la liste devait être gérée (maîtrisée) par le site qui ouvre son service.
D'où le besoin de catégories virtuelles cachées... Ce qui simplifie la programmation de 2000%.

Principes de la maîtrise par catégorie virtuelle cachée:

1er cas. Requête d'un non partenaire (accès libre) => on peut forcer la catégorie cachée "nonpart" (ids=5,6,23,48,56,76,78,98,126), sachant que le maxreturn (devenu ws-limit) s'applique.

2eme cas. Requête de mon partenaire (mon blog) => une (autre) catégorie "monblog" cachée (ids=1,2,3,,4,5,6,7,8,9,....,2000), sachant que dans sa clé d'accès gérée par des dates on trouve sa "limit" et quelle peut être à 25.

Ce qui permet de demander (dans les 2 cas mais évidemment cat=76 n'est pas la même suivant le cas):

?type=list&list=23,42,90&cat=77
?type=list&list=23,42,90,125,178,298&cat=76
?type=random&cat=76&limit=10

(ws-limit à 3)
Résultats du 1er cas (libre) => photo 23 pour les 2 premières requêtes et 3 photos de "nonpart" pour la dernière(*).
(*) La première requête demande la cat 77, oui, mais dans la table des clés d'accès je peux lui forcer la catégorie 76.

Résultats de l'accès de "mon blog" => les requêtes renvoient 3, puis 6, puis 10 photos(*).
(*) En supposant que la catégorie 77 contiennent des photos publiques dont les 23,42 et 90.

Tout ceci marche(*) déjà sauf que la catégorie 76 est visible sur ma galerie et cela ne correspond pas au besoin de ma galerie.
(*): j'ai un petit bug sur l'analyse de clé (clé qui a évoluée).

Pour revenir à ta demande, j'ai deux solutions soit je livre avec list= et je livre en plus un patch (MOD) qui casse list=.
Ou je livre mais list= est en commentaire, pour ceux qui le souhaitent.
A moins que tu me proposes une solution sécurisée (une autre bonne idée).

Je penche pour la solution '//'.

8-)

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact