[fonctionelle] Api WRI pour l'export points/commentaires/photos

Répondre

Smileys
:D ;) :o :? 8) :lol: :oops: :twisted: :roll: :ours: :fille: :calimero: :troll: :saint: :forb: :avocat: :mouton: :rando: :vaudou: :noel: :) :( :shock: :x :P :cry: :excl: :?: :idea: :arrow: :| :sleep: :geek: :blue: :mrgreen:
Voir plus de smileys

Les BBCodes sont activés
[img] est activé
[url] est activé
Les smileys sont activés

Revue du sujet
   

Si vous souhaitez joindre un ou plusieurs fichiers, complétez les indications suivantes.

Taille maximum par fichier joint : 10 Mio.

Étendre la vue Revue du sujet : [fonctionelle] Api WRI pour l'export points/commentaires/photos

par sly » 17 févr. 2015, 18:10

J'enlève le mot clé "proposition" car ce n'est plus à cet état, c'est vraiment en production, même s'il y a encore des tas d'évolutions envisagées

par sly » 28 juil. 2014, 17:42

leosw a écrit : Par API affichage, je voulais dire lecture seule.
A ok ! Je n'avais pas compris ça. Ma remarque ci-avant concernant l'api d'affichage devient caduque.

Et ça permet de limiter l'injection de code (comment s'assurer que le partenaire est bien sécurisé contre les robots ?)
On ne peut pas s'en assurer, il faut donc tester avec soin que tous les paramètres qui seront passé par cette api seront bien conforme au format attendu.
(note: ce code est déjà opérationnel pour l'api actuelle)
Pour contrer l'injection de code, il suffit d'utiliser des switch pour gérer les variables GET, je pense que ça suffit vu que c'est de la lecture seule.
Tant qu'on accepte pas de modif, le risque de XSS (http://fr.wikipedia.org/wiki/Cross-site_scripting ) reste faible, et en interne, il faut de toute façon que la fonction de récupération des données n'accepte pas n'importe quoi sous peine de faire planter la requête SQL donc autant mutualiser.

par sly » 28 juil. 2014, 17:37

Dominique a écrit : Attention tout de même à la longueur de l'url
Excellente remarque, en appel xml rpc, on aurait pas cette limite de longueur de l'url. Je pense qu'on a de la marge pour l'instant, mais à garder à l'esprit, surtout, je pense, si on fait évoluer vers une API de modification (une fiche complète ne tiendra certainement pas dans l'url) mais à ça moment là, il sera jamais trop tard d'ajouter un payload xml

par Dominique » 28 juil. 2014, 16:30

leosw a écrit :Par API affichage, je voulais dire lecture seule. Et ça permet de limiter l'injection de code (comment s'assurer que le partenaire est bien sécurisé contre les robots ?)

Pour contrer l'injection de code, il suffit d'utiliser des switch pour gérer les variables GET, je pense que ça suffit vu que c'est de la lecture seule.
En mofification, en utilisant la même url action que le formulaire html: wri/point_ajout_commentaire/1245... qui va s'assurer que l'utilisateur est bien connecté...

par leosw » 28 juil. 2014, 14:05

Code : Tout sélectionner

API GET -> dans une phase 1, je pense en en effet à de l'extraction de données, donc ni affichage (c'est quoi ça une "api d'affichage" ?), ni ajout/modif mais pourquoi pas pour plus tard. 
Par API affichage, je voulais dire lecture seule. Et ça permet de limiter l'injection de code (comment s'assurer que le partenaire est bien sécurisé contre les robots ?)

Pour contrer l'injection de code, il suffit d'utiliser des switch pour gérer les variables GET, je pense que ça suffit vu que c'est de la lecture seule.

par Dominique » 28 juil. 2014, 13:42

Sly a écrit :API XML ? genre XML RPC ? ben pouquoi pas si on me prouve les avantages, mais ça me semble plutôt compliqué pour pas grand chose.
Depuis que tu as dit ça je cherche mais je ne vois en effet pas d'avatage. J'ai du vouloir copier GML.
Avec un parse_xlml (get_file_contents(url)) on s'en tire très bien mais $_GET['par'] est nettement plus simple. Attention tout de même à la longueur de l'url et à l'injection de code...
A la rigueur si l'arbo des données est complexe ou si on a déjà un package qui traite le protocole..

par Dominique » 25 juil. 2014, 18:16

sly a écrit :smartphone, j'ai android 2.3 avec firefox mobile :
- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran... 
OL n'est pas terrible en effet, certains contrôles ne répondent pas, mais ça reste jouable, et pour compléter, y'a www.refuges.info/mobile ;-)
- La localisation ne marche pas, ce qui est un comble sur un mobile
ici ça marche
mais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.
ici ça marche
- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer.
ici ça marche.
Pb résolu: tous ces pb avec l'appli chrome qui [censuré] complètement
Ça marche comme chez toi avec l'explo livré de base par Samsung

par Dominique » 24 juil. 2014, 19:34

sly a écrit : -- ou pour des "sites partenaires" mais je ne sais pas si c'est toujours utilisé
Je confirme
http://chemineur.fr
et, par ricochet : http://vttrack.fr couche hébergements

par leosw » 24 juil. 2014, 19:10

Il y a actuellement 2 API sur refuges.info
Je dirais même 3, 2 http GET effectivement et une troisième, que je suis pour le moment le seul à utiliser, qui est :
http://www.refuges.info/point-geojson/IdDuPoint

Et qui comme l'indique le bug ici va bientôt devenir :
http://www.refuges.info/point-json/IdDuPoint

Et oui, leaflet utilise l'exportation, d'où la création d'un format geojson spécifique.

par sly » 24 juil. 2014, 19:03

Comme promis, une mini page indiquant comment fonctionne l'api actuelle (celle qui exporte des points) et qui est utilisé par :
- OL
- leaflet (confirmation leo ?)
- la page exportation : http://www.refuges.info/formulaire_exportations/
-- qui elle peut servir soit depuis le formulaire pré-cité
-- ou pour des "sites partenaires" mais je ne sais pas si c'est toujours utilisé

http://www.refuges.info/wiki/api-refuges.info/

par Dominique » 24 juil. 2014, 17:19

leosw a écrit :Pour les projets à refuser, vu que c'est fait et que ça va partir à la poubelle, voici une idée de style que j'ai fait pour un projet (abandonné) et qui pourrait bien aller à WRI :

http://leo-serre.legtux.org/OutdoorSports/redirect.php
Moi je trouve la présentation très bien
Reste àfaire les pages de consultation de fiche, création de point, saisie de commentaires...

par leosw » 24 juil. 2014, 15:00

Pour les projets à refuser, vu que c'est fait et que ça va partir à la poubelle, voici une idée de style que j'ai fait pour un projet (abandonné) et qui pourrait bien aller à WRI :

http://leo-serre.legtux.org/OutdoorSports/redirect.php

par sly » 24 juil. 2014, 12:44

API GET -> dans une phase 1, je pense en en effet à de l'extraction de données, donc ni affichage (c'est quoi ça une "api d'affichage" ?), ni ajout/modif mais pourquoi pas pour plus tard.

API XML ? genre XML RPC ? ben pouquoi pas si on me prouve les avantages, mais ça me semble plutôt compliqué pour pas grand chose.

API programme -> de fait, elle existe déjà, c'est l'ensemble de ce qu'il y a dans le dossier /modeles mais j'aimerais rationaliser en fusionnant la syntaxe de l'API php et de l'API GET

phpBB, même (grosse) méfiance que leo. Ce qui fait la qualité d'un programme n'est pas son langage, son framework, son MVC ou autres critères techniques, ce sont les humains qui y passent du temps pour l'embellir (et je commence sérieusement à croire que dans un développement, l'étape initial le "ça marche" c'est 10% du tout avant d'obtenir un truc donc chaque détail a été pensé, chaque protection vérifié, chaque accès modération établie, etc. Et je ne suis pas super chaud pour tout refaire.

Rien n'empêche de faire une démo cependant, mais le risque et de la voir "refusé" et donc temps passé pour rien

smartphone, j'ai android 2.3 avec firefox mobile :
- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran...
OL n'est pas terrible en effet, certains contrôles ne répondent pas, mais ça reste jouable, et pour compléter, y'a www.refuges.info/mobile ;-)
- La localisation ne marche pas, ce qui est un comble sur un mobile
ici ça marche
mais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.
ici ça marche
- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer.
ici ça marche.
Seul regret, la saisi des coordonnées plutôt que "je suis devant la porte" ;-) et le viseur jaune que je n'arrive pas à déplacer
L'ajout d'un commentaire semble lui avoir un mini bug, le champ de saisie est énorme, mais j'imagine que ça ne doit pas être trop dur à corriger en css

Difficuté : identifier toutes les petites fonctions bien utiles accumulées au ciurs du temps. Je compte sur Sly :)
Grosse difficulté, car le sly, il n'a pas vraiment envie de refaire sans avoir la sensation que ça apporte vraiment un truc. Et en effet, il y a plein de petits détails de ce type accumulés au cours des demandes qui font que wri est ce qu'il est.

par leosw » 24 juil. 2014, 09:22

- Penses tu à une API affichage ou aussi saisie ?
Dans un premier temps je pensais affichage, parce que c'est le plus simple, ensuite saisie si la demande est là et si l'API fonctionne bien.
Je partais sur une idée API PHP, mais j'avoue ne pas comprendre ce que tu veux dire par XML.
- Je suis en train d'étudier les apps mobiles. Une appli WRI risque bien d'être mon premier essai et j'aurai besoin d'une API serveur.
Alors je pense que tout le monde sur Terre est au courant que je fais une appli pour Firefox OS (visible sur leo.refuges.info/mobile) :). Cette appli est une WebAPP, c'est à dire qu'elle a de nombreuse fonctionnalités :
* Site web mobile accessible depuis tous navigateur (mobile ou bureau)
* Application intégrée aux smartphones/tablettes... équipés de Firefox OS
* Application intégrée aux smartphones/tablettes... équipés d'Android (Firefox Mobile requis)
* Application intégrée aux PC équipés de Windows (Firefox requis)
* Application intégrée aux PC équipés de Linux(Firefox requis)
* Application intégrée aux PC équipés de Mac OS (Firefox requis)
Autre point de vue : je pense depuis un moment à repartir sur une base PhpBB3, en laissant PhpBB gérer les fiches, commentaires, photos et toute la saisie, recherche, news,...
Je suis désolé mais je suis réticent sur ce point, j'ai toujours privilégié la maitrise totale du CMS et même si c'est plus simple sur certains points, je trouve ça au final plus compliqué... L'utilisation de phpBB pour le forum et l'authentification centralisée est pour moi justifiée, mais pour la gestion des fiches je ne trouve pas, ça limite sur les panneaux d'administration, etc.
Pour en revenir au sujet API : il devient trivial avec les templates PhpBB. On peut développer un template "mobiles", un template "XML", ... Ce sont des fichiers à chaque fois bien séparés et indépendants du code PHP du kernel.
Tu as raison, mais en utilisant un modèle MVC c'est aussi simple, une page php s'occupe de la récupération et mise en variable, la vue n'est autre que le fichier.extension avec l'extension choisie par l'utilisateur. Comme je l'ai fait pour l'export en json des fiches points.
- que constatez vous sur vos mobiles et quels O.S. avez vous ?
WRI est votre oeuvre et j'arrive après la guerre, mais je me permet de critiquer. Il y a eu une mode OL où le manque de choix dirigait tout le monde vers cette librairie, aujourd'hui je pense que les applications migrent toutes vers leaflet (openstreetmap.org pour l'exemple), j'ai utilisé leaflet et j'ai pu tout faire marcher sans rien coder, les plugins existaient déjà tous.


Pour conclure, je suis désolé d'être réticent à phpBB, mais je ne suis pas certain que ce soit le bon choix.

par Dominique » 23 juil. 2014, 20:14

Salut

Quelques réflexion assez générales et diverses propositions en vrac

- Je suis fan de l'idée d'API

- Penses tu à une API affichage ou aussi saisie ?

- Faut il partir sur une API "programmme" (PHP) ou XML (URL refuges.info/extractions/format...) ou autre (voyez vous une interface adapté - lecture - écriture genre GML) ?

- Je suis en train d'étudier les apps mobiles. Une appli WRI risque bien d'être mon premier essai et j'aurai besoin d'une API serveur.

- Il serait intéressant pour la modularité du site de sortir la partie gestion des polygones : On peut parfaitement en faire un sous systéme isolé (avec sa partie saisie des polygones et infos) et l'interfacer comme une API. D'ailleurs cette API existe déja : http://refuges.info/exportations/locali ... &lat=45.42 puisque je m'en sers pour localiser les points chemineur (dans une version pas encore livrée).


Autre point de vue : je pense depuis un moment à repartir sur une base PhpBB3, en laissant PhpBB gérer les fiches, commentaires, photos et toute la saisie, recherche, news,... 

Ça permettrait de factoriser un max de code avec PhpBB.

L'idée est d'aller jusqu'au bout de 1 fiche = 1 topic du forum "refuges", avec un template d'affichage similaire à l'affichage de la fiche WRI actuelle quand on veut visualiser le topic comme un point. Les commentaires du point seraient les posts possédant un flag adéquat. Cela permet de factoriser la saisie et de passer rapidement des commentaires de la fiche au forum et vice-versa.

Les données des fiches (mur, poil, ... géographiques) seraient ajoutées à la table phpbb_topics et on laisse PhpBB gérer l'accès lecture/écriture (il y a 2 ou 3 lignes de code à ajouter au kernel pour faire le lien avec le template point).

Pas de crainte, je vois bien comment faire en minimisant les interactions avec le code PhpBB et si j'ai un peu merdé sur la conversion chemineur, c'est surtout au niveau de la synchro et dédoublonage avec les autres sites. Je pense être prêt pour WRI et faire une maquette.

Je maitrise assez bien la récup de bases et les templates.



Pour en revenir au sujet API : il devient trivial avec les templates PhpBB. On peut développer un template "mobiles", un template "XML", ... Ce sont des fichiers à chaque fois bien séparés et indépendants du code PHP du kernel.

Dans ce cas, je prendrais en charge la reprise de l'interface actuel + une sortie flux XML lecture/écriture + une interface mobile si Léo m'en donne la syntaxe.



Autre point de vue qui n'a rien à voir : j'ai acheté récement un smartphone (je n'en étais jusque là qu'au mobile où on parle dedans et c'est tout) et je peine sur WRI

- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran... 

- La localisation ne marche pas, ce qui est un comble sur un mobile

- que constatez vous sur vos mobiles et quels O.S. avez vous ?

Je pensais  que OL 2.12 était compatible mobile mais pas testé = ne marche pas. Gros travail pour moi pour passer sur 2.13 (ou attendre 2.14 qui ne devrait pas tarder ou OL V3 beta qui semble assez stable et sympa sur mobile) et faire un truc qui marche aussi sur smartphone.

- Les pages d'accueil et de points passent assez bien mais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.

- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer. De plus, la barre de menu surgit intempestivement (c'est déja le cas mais avec un tout petit écran, c'est redibitoire) notamment sur un pavé de saisie ce qui fait qu'au lieu d'insérer un caractère, on se retrouve sur la page des cartes...

Je n'ai pas encore regardé ce qui pose pb mais  faudra en profiter pour refaire un template de saisie propre.

Quelle est votre expérience de l'entrée de points ou commentaires via mobiles ?

Le but est de se pointer devant la cabane et de créer ou comenter le point en un nombre réduit de clics (devrais-je dire tapotage ?)


Je résume la modularité et factorisation de mes prooositions:

- Un coeur sur base PhpBB3 + un min de modifs au kernel (moi)

- Une moulinette de récup de la base + photos + forum (moi)

- Un template PhpBB standard pour le forum (un de ceux de PhpBB)

- Un template PhpBB à coder pour l'affichage des fiches et des pages d'accueil (moi)

- Un template PhpBB entrée/sorties fiches + commentaires format XML (moi)

- Un template PhpBB spécifique API mobile si Léo m'en donne la syntaxe.

- Un module localisation d'un point par rapport à une base de polyones et données associées (interface ouvert à d'autres sites) localisation.php?lon=5&lat=45  Dans un premier temps, on peut utiliser le site de prod. Aprés, j'apprécierais un coup de main de SLY car je ne me suis pas trop investi dans les postgres.

- Le sous systéme d'affichage de cartes existant mais à reprendre pour une bonne gestion des mobiles et à documenter (il s'agit de javascript entièrement objet suivant les règles de codage openlayers mais une bonne doc ne nuit pas). Point indépendant de la refonte API. Utiliser l'existant pour la maquette.

- Un interface mobile (actuel Léo)

- Une ou des apps smartphone à venir

Difficuté : identifier toutes les petites fonctions bien utiles accumulées au ciurs du temps. Je compte sur Sly :)


Je vais essayer de faire une maquette de tout ça pour septembre. Je suis sur que vos idées y ajouteront des +. Ma dispo étant incertaine, ne m'attendez pas pour progresser de votre côté.

Haut