omigeot-ccpo/Gismeaux — comment on commit cf24e630e7bf9da6fe5a69c779b601f186377b41
File: apps/cadastre/function_sql.txt line 29
By jdechamp:

Je vous rejoins complètement, Pg doit générer les variables et sortir le tous dans un format d'échange près à être digéré par php. Pour ma part je pensais au xml, pour Json je ne connais pas donc je vais regarder

Jean-Luc Déchamp
Service SIG Ville de Meaux

-----Message d'origine-----
De : omigeot-ccpo [mailto:reply@reply.github.com]
Envoyé : jeudi 17 novembre 2011 17:45
À : Dechamp Jean Luc
Objet : Re: [Gismeaux] Merge pull request #2 from rleguay/master (cf24e63)

C'est assez vrai, mais elle est liée à la "skin", laquelle est - à tort
ou à raison - dépendante de la commune. La question est donc de savoir
si on souhaite conserver une interface personnalisable par commune ou pas.

De manière plus générale, il y a un risque à faire retourner du HTML par
une fonction SQL. Ca oblige notamment à avoir le code PHP en parfaite
synchronisation (en termes de version) avec la base, ce qui :

* rend le tout moins robuste
* ne permet plus vraiment de modifier la présentation (le PHP, on va
dire) sans toucher aux données

Je n'ai pas fait de tests de performances, mais c'est vraiment plus
efficace en laissant Postgres faire le boulot de PHP? Entre autres
alternatives, on pourrait :

* laisser la fonction PG générer l'essentiel de la page (au moins la
partie variable), la partie PHP n'étant plus appelée à changer
* plutôt que de générer des données "mises en forme" dans le PG, on
génère un truc plus neutre (JSON, ou à l'extrême limite XML), lequel
sera interprété à moindre coût (surtout pour JSON) pour le PHP

---
Reply to this email directly or view it on GitHub:
https://github.com/omigeot-ccpo/Gismeaux/commit/cf24e630e7bf9da6fe5a69c779b601f186377b41#commitcomment-727998