[codage] Bien choisir notre modèle MVC

[Dominique]

Pas super en terme de lisibilité

+

Qu'est-ce qui t'embête à ce point avec le mettre dans .htaccess ? où c'est juste que tu n'as pas réussi à configurer ton apache pour qu'il s'en serve ?

Rien de spécial, ça marche chez moi
C'était juste pour répondre à ta question sur la gymnastique de déplacement de fichier

[leosw]

Salut,

Juste une question sur le modèle, il ne serait pas plus intelligent d'appeler les fonctions de mise en forme dans la vue ? De manière à ce que les liens ne soit pas transformés lors d'un export ?

Ça corrigerait les pbs de lien internes dans le site mobile et aussi les ps d'adresses mails qui ne s'affichent pas correctement.

Léo

[sly]

Juste une question sur le modèle, il ne serait pas plus intelligent d'appeler les fonctions de mise en forme dans la vue ?

Si, et il me semble que ça devrait, tu parles d'un endroit précis ? c'est peut-être à corriger....

De manière à ce que les liens ne soit pas transformés lors d'un export ?

Ça corrigerait les pbs de lien internes dans le site mobile et aussi les ps d'adresses mails qui ne s'affichent pas correctement.

Ça a peut-être changé, mais l'export ne fait aucune mise en forme, il renvoi du bbcode ce me semble, la mise en forme étant à la charge de l'exploitant.

Mais précise de quoi tu parles que je regarde de plus près

[leosw]

Salut,

Pour ce qui est de l'export je parle de l'export d'un point. Le seul qui existe pour le moment c'est du json qui est généré via la vue point.json

Comme on peut le voir ici, il n'y a pas d'appel à la fonction de décodage, la chaine est directement en html :


En fait tout se passe dans le contrôleur ici. Du coup, dans la vue, on ne peut qu'afficher le code décodé, avec des liens en durs vers les fiches et non l'id récupérable simplement.

Il y a deux solutions à mes yeux si l'on laisse en l'état :

* On parse la longue URL
* On créé un cas bizarre un peu partout (ce que j'ai fait dans master), ce qui conduit à une condition dans la conversion des liens internes et à tout une magouille par la suite pour décoder uniquement les liens internes et non tout le reste qui est en HTML.

Léo

[sly]

Pour ce qui est de l'export je parle de l'export d'un point. Le seul qui existe pour le moment c'est du json qui est généré via la vue point.json

A chaque fois ça m'embrouille, pour moi, les exports sont là :
https://github.com/sletuffe/www.refuges ... portations

De mon point de vue, la solution de la vue point.json pour faire un export est une magouille que j'avais compris comme temporaire, la solution d'avenir étant selon moi la future api qui exportera, dans un format type xml et json des commentaires, des points, des massifs, etc.
Qui eux ne seront pas retouchés avant "export"

Comme on peut le voir ici, il n'y a pas d'appel à la fonction de décodage, la chaine est directement en html :

Cohérent avec :
http://www.refuges.info/forum/viewtopic ... 5221#18827
"ne plus mettre un seul appel de fonction dans les vues/*.html"

Du coup, dans la vue, on ne peut qu'afficher le code décodé, avec des liens en durs vers les fiches et non l'id récupérable simplement.

Ce qu'il te faut c'est un export de la base, l'id n'a presque pas de raison d'être transmis à la vue, vu qu'elle ne l'affiche pas (bon, si, mais juste coup de bol)

* On parse la longue URL

non

* On créé un cas bizarre un peu partout (ce que j'ai fait dans master), ce qui conduit à une condition dans la conversion des liens internes

Beurk, argh, kof kof, en effet non. Si on manipule la vue dans les includes ou les modèle on est sur de se planter, c'est d'ailleurs coup de vol que global $vue; nous la ramène, sitôt qu'on passera en object avec cette propriété comme privée, ça ne marchera plus.

et à tout une magouille par la suite pour décoder uniquement les liens internes et non tout le reste qui est en HTML.

Glargl, je me suis pendu ! En effet, ça ne va pas, quelle galère.
Ta vue ne devrait pas intégrer de code, donc clairement, on ne fait pas ce qu'il faut. Il faut se rendre à l'évidence, on a voulu mutualiser le controlleur "point.php", mais ta vue n'a pas les mêmes besoins que la mienne (point.html) donc on va se retrouver avec des if de partout et ça ne sera pas lisible et des récup de données non utile.

Solution 1) Vraiment faire avancer l'api et que ton code en js fasse des json requests
Solution 2) écrire un nouveau controlleur point-mobile.php

[leosw]

Solution 1) Vraiment faire avancer l'api et que ton code en js fasse des json requests

Oui, j'aimerais pouvoir faire des applis sympa (avec l'ajout de commentaire par exemple).

Je vais me lancer dans la création du dossier API pour mettre tout ça au propre. Il viendra remplacer l'exportation dans le futur.

Mais comme ça risque de mettre 2 mois, j'aimerais garder ma branche pour l'appli mobile, ce sera donc une branche dev-api pour l'API, je m'en occupe dès que je commencerais

Léo

[sly]

Oui, j'aimerais pouvoir faire des applis sympa (avec l'ajout de commentaire par exemple).

Ha ouais, carrément API R/W alors !

Je vais me lancer dans la création du dossier API pour mettre tout ça au propre. Il viendra remplacer l'exportation dans le futur.

Et si on commençait par écrire une mini doc sur la forme des appels, les formats de sortie possible et voir un peu ce que chacun a en tête histoire de voir si on va tous dans la même direction avant de taper du code ?

ps: pour moi, un dossier api est inutile avec le modèle MVC, mais un appel de la forme http://www.refuges.info/api?je_sais_pas_quoi

Mais comme ça risque de mettre 2 mois, j'aimerais garder ma branche pour l'appli mobile, ce sera donc une branche dev-api pour l'API, je m'en occupe dès que je commencerais :)

ça me plairait de pouvoir bosser dessus aussi, dès que le coeur t'en dis, créer cette branche et je la "pull" pour moi aussi faire des essais

[Dominique]

De mon point de vue, la solution de la vue point.json pour faire un export est une magouille que j'avais compris comme temporaire, la solution d'avenir étant selon moi la future api qui exportera, dans un format type xml et json des commentaires, des points, des massifs, etc.
Qui eux ne seront pas retouchés avant "export"

De mon point de vue ça me semble trés propre: sortir du json est du même niveau que sortir du html ou du xml: c'est une vue comme une autre. L'API étant au niveau PHP qui appelle la vue.

Pour le reste, je dirais pas de code dans les vues en effet. A l'API au sens PHP de calculer chaque version codée ou non de l'adresse mail...

Je suid déformé par mon idée d'utiliser le système de template de PHPbb. Mais comme je n'ai pas le temps d'y travailler je ne vous casserai pas les pieds pour l'instant

[sly]

De mon point de vue, la solution de la vue point.json pour faire un export est une magouille que j'avais compris comme temporaire, la solution d'avenir étant selon moi la future api qui exportera, dans un format type xml et json des commentaires, des points, des massifs, etc.
Qui eux ne seront pas retouchés avant "export"

De mon point de vue ça me semble trés propre: sortir du json est du même niveau que sortir du html ou du xml: c'est une vue comme une autre. L'API étant au niveau PHP qui appelle la vue.

Ma phrase n'était pas claire, mais je voulais dire : "de mon point de vue, la solution retenue dans le fichier point.json pour faire un export est une magouille" car elle consiste à trafiquer les données reçues du controlleur pour remonter aux données du modèle.
(comme parser la variable qui contient un lien pour retrouver l'id du point)
Sinon oui, si le contenu à fournir en json était strictement le même que celui voulu en html, oui, ça marcherait.

Bon, d'ailleurs, ça marche presque presque, y'a juste cette histoire de liens inter-fiches et d'email traffiquée en code js pour l'obfusquer qui ne ne comporte pas bien en HTML5 si j'ai bien compris.
Une solution temporaire serait de changer le controleur point.php pour lui faire sortir le contenu des champs aussi avec l'opération "fromBBtojson" comme il y a celle "fromBBtohtml" (avec email en claire, et lien inter-fiche au format qui va)

L'autre étant d'accepter une entorse au "pas d'appel fonction dans les vues" pour tolérer un appel au formatage qui passe du bbcode vers ce qui est le mieux pour la vue souhaitée

[leosw]

Salut à tous,

Alors comme je n'avait jamais fait d'objet en PHP, ou vu un modèle MVC ailleurs, je me suis un peu documenté. La solution que je retiens pour l'API (à contre-cœur car il y a pas mal de compromis ) est la suivante :

* Vues, réécriture complète (en même temps pas de surprise)
* Contrôleurs, là on doit réécrire, car l'API a plein de paramètres (format, nombre de commentaires..., donc on ne peut pas réutiliser)
* Modèles, pareil, on appelle ce qui existe mais on modifie un peu.

Enfin, pour ce que vous appelez le contrôleur (controlleur.php à la racine) et que j'ai l'habitude d'appeler la redirection, là je vais en faire un nouveau qui sera dans API. Parce qu'à mes yeux c'est nouveau.

Donc pour conclure, je pense que je vais faire ça comme arborescence :

Code : Tout sélectionner

/modèles/point.php (avec les fonction de questionnement de bdd (avec paramètres genre nb_commentaires)
/controlleurs/api/point.php qui met en place des variables qu'on utilise dans la vue en récupérant les paramètres de l'API
/vue/api/point.json
/vue/api/point.pdf (là on bricole, car on utilise une class externe, donc c'est du PHP comme il ne faudrait pas)
/api/controlleur.php (pour garder votre nom, c'est là que tout ce qui pointe vers /api/quelquechose est redirigé, on traite l'URL)
/api/doc/ la doc

Je vais avouer que je trouve ça pas terrible. Pour moi (et c'est ce que je vais faire avec le site mobile et l'application mobile) il faut une API surpuissante qui réponde à tous nos besoins, et dessus un front-end qui se serve de l'API comme pour Mr. Tout le Monde. De manière à ce que la séparation mise en page/base de donnée soit nette.

Mais comme il semble que je ne soit pas le seul têtu par ici...

Léo

[sly]

* Vues, réécriture complète (en même temps pas de surprise)
* Contrôleurs, là on doit réécrire, car l'API a plein de paramètres (format, nombre de commentaires..., donc on ne peut pas réutiliser)
* Modèles, pareil, on appelle ce qui existe mais on modifie un peu.

ça me va ;-)

Enfin, pour ce que vous appelez le contrôleur (controlleur.php à la racine) et que j'ai l'habitude d'appeler la redirection

J'ai choisi ce nom car je ne savais pas comment l'appeler, mais ce n'est pas en phase avec ce qui se fait dans les autres framework, l'appelation la plus répandue c'est "routing" ou des "routes"
exemple :
http://symfony.com/fr/doc/current/book/routing.html
"Ceci est le but du routeur Symfony2 : faire correspondre l'URL d'une requête à un contrôleur"

Je suis donc en faveur au moins de le renommer en "routage.php"
Et si quelqu'un à une idée, comme la maintenance de ce fichier est un peu pénible (longue liste de url <-> controlleur) si quelqu'un a une idée pour ranger ça autrement, je suis preneur.

une version hybride pouvant être :
si url = "/api/*" alors déléguer toutes les urls de type "/api/*" à un autre sous-routeur

edit : en fait, c'est pile ce que tu proposes après, appelons le aussi "routage.php" ou "routes.php"

Donc pour conclure, je pense que je vais faire ça comme arborescence :

Code : Tout sélectionner

/modèles/point.php (avec les fonction de questionnement de bdd (avec paramètres genre nb_commentaires)
/controlleurs/api/point.php qui met en place des variables qu'on utilise dans la vue en récupérant les paramètres de l'API
/vue/api/point.json
/vue/api/point.pdf (là on bricole, car on utilise une class externe, donc c'est du PHP comme il ne faudrait pas)
/api/controlleur.php (pour garder votre nom, c'est là que tout ce qui pointe vers /api/quelquechose est redirigé, on traite l'URL)
/api/doc/ la doc

ça me va pas bien ;-)
les polygones et les commentaires pouvant se rajouter par la suite.

Je vais avouer que je trouve ça pas terrible. Pour moi (et c'est ce que je vais faire avec le site mobile et l'application mobile) il faut une API surpuissante qui réponde à tous nos besoins

Je ne sais pas si je te comprends bien, mais je suis près à continuer à en parler, c'est quoi "surpuissante" selon toi ?
Couvrir les besoins que tu as listé dans ton schéma peut se faire soit en faisant plusieurs appels "simples" par besoin,
ou en un seul appel par besoin, ou autres options entre le deux.
Mais je pense que si tu as en tête 1 appel = 1 besoin la solution controlleur+vue me semble plus adaptée (tu n'es pas obligé de vérifier tous les usages de l'appel X pour vior si d'autres s'en servent avant de le faire évoluer)

ps: faudrait p'tet qu'on se fasse un réunion IRC à 3 (+yip ?) ensemble, ça débroussaillerait sans doute mieux et plus rapidement. un avis ?

[leosw]

En fait, pour répondre à la fin de ton message, on a tous nos habitudes, et par exemple Dom avec son phpBB et OpenLayers, et moi avec ma division backend/frontend.

Donc pour une API surpuissante, je pense à une API qui gère l'authentification (indispensable si on veut y ajouter l'écriture), et un site qui ne se connecte jamais directement à la base de donnée.

Mais on peut faire comme vous avez toujours fait : un noyau API+Site tout public, et à côté des applications qui sont basées sur l'API.

Pour IRC ça me va, en soirée par contre.

[sly]

Donc pour une API surpuissante, je pense à une API qui gère l'authentification (indispensable si on veut y ajouter l'écriture), et un site qui ne se connecte jamais directement à la base de donnée.

Compris pour l'aspect frontend/backend qu'on peut encore imaginer en deux formes, un frontend full javascript qui fait des requêtes http au backend (mais quid du référencement du site ? j'ai des doutes sur cette option), ou un frontend php qui appel, par des requêtes http (genre fopen(http://truc/api/)

Mais prenons un cas concret, pour afficher la page d'un point dans un navigateur, à supposer que tu vas te baser, en js, sur des appels http au backend, combien fera tu d'appels ?
et que vont ils récupérer ?

Mais on peut faire comme vous avez toujours fait : un noyau API+Site tout public, et à côté des applications qui sont basées sur l'API.

C'est ce que j'ai en tête, mais avec un rapprochement des deux API (l'api noyau et l'api http)
Idéalement qu'elles prennent les même paramètres d'entré (moins une transformation http->array ou array->http)
et une sortie similaire (moins une transformation près array->gml ou json)

L'idée étant d'avoir un code malgré tout très proche, mais sans devoir faire, en php un fopen("http://api") puis parser du json en php pour en faire une array, car il faut bien manipulier les données ensuite.

[leosw]

Je vais refaire naitre le débat. Mais maintenant je qu'ai la tête dedans, je trouve effectivement énormement plus simple de coder nos modèles comme des classes et donc faire de l'objet.

Avec un objet point par exemple et les méhodes qui vont avec (récupérer_x_commentaires, récupérer_x_points_proches, récuperer_infos_générales, récupérer_dernier_post_forum, modifier, ajout_commentaire...)

Sans vouloir refaire naitre les tensions, est-ce que vous ne pensez pas que ça serait plus simple ? Ça rendrait le modèle franchement utilisable partout...

Léo

[sly]

Moi, j'ai toujours pensé que ça serait plus ou moins pareil que ce qu'on a, ce qui y a à gagner c'est un peu de formalisme et de rangement au prix d'un re-développement non négligeable.
"Plus simple", je pense que c'est une tromperie mentale, ça n'est plus simple que pour celui qui a développé le modèle et qui l'a donc bien en tête, et a compris sa philosophie.

Aujourd'hui, c'est moi qui l'ai développé, je l'ai donc bien en tête et c'est donc plus facile pour moi et plus difficile pour vous de "vous plonger dans un plat de nouille"

Demain, si c'est toi qui développe le modèle, on inversera les rôles. Et je pense que objet ou pas n'y change pas grand chose.

Maintenant, je sais que dominique aime l'idée, donc si vous êtes deux, allez-y, mettez vous d'accord sur les méthodes, codez les, indiquer comment vous migrez d'avant à après et go !

J'indique toutefois mon engagement dans ce projet : Je n'ai aucune envie de re-développer ce que j'ai déjà fais tant que je ne suis pas convaincu que le jeu en vaut la chandelle (et puis j'ai pas des masses de temps libre). Mais je ferais bien sûr l'effort d'utiliser le "nouveau modèle" pour tout nouveau développement une fois qu'il sera en place et documenté. Dans la mesure de mon possible j'indiquerais mon avis au fûr et à mesure de l'avancement pour trouver la balance entre factorisation (qui est maximale aujourd'hui) et utilisation (qui est compliquée aujourd'hui)

Ton avis dominique ?