+sly a écrit :Pas super en terme de lisibilité
Rien de spécial, ça marche chez moiQu'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 ?
Si, et il me semble que ça devrait, tu parles d'un endroit précis ? c'est peut-être à corriger....leosw a écrit : Juste une question sur le modèle, il ne serait pas plus intelligent d'appeler les fonctions de mise en forme dans la vue ?
Ç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.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 chaque fois ça m'embrouille, pour moi, les exports sont là :leosw a écrit : 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
Cohérent avec :leosw a écrit : Comme on peut le voir ici, il n'y a pas d'appel à la fonction de décodage, la chaine est directement en html :
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)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.
non* On parse la longue URL
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.* 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
Glargl, je me suis pendu ! En effet, ça ne va pas, quelle galère.et à tout une magouille par la suite pour décoder uniquement les liens internes et non tout le reste qui est en HTML.
Oui, j'aimerais pouvoir faire des applis sympa (avec l'ajout de commentaire par exemple).Solution 1) Vraiment faire avancer l'api et que ton code en js fasse des json requests
Ha ouais, carrément API R/W alors !leosw a écrit : Oui, j'aimerais pouvoir faire des applis sympa (avec l'ajout de commentaire par exemple).
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 ?leosw a écrit : 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.
ç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 essaisMais 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 :)
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.sly a écrit :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"
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.Dominique a écrit :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.sly a écrit :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"
) est la suivante :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 ;-)leosw a écrit : * 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.
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"leosw a écrit : Enfin, pour ce que vous appelez le contrôleur (controlleur.php à la racine) et que j'ai l'habitude d'appeler la redirection
ça me va pas bien ;-)leosw a écrit : 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 ne sais pas si je te comprends bien, mais je suis près à continuer à en parler, c'est quoi "surpuissante" selon toi ?leosw a écrit : 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
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/)leosw a écrit : 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.
C'est ce que j'ai en tête, mais avec un rapprochement des deux API (l'api noyau et l'api http)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.