[codage] Bien choisir notre modèle MVC

Problèmes, bugs et difficultés rencontrés sur le site.
Avatar du membre
Dominique
Messages : 3704
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :Ton avis dominique ?
Mon cher Léo,

C’est toujours avec délectation et intérêt que je suis tes propositions. Je te dois déjà deux belles découvertes avec Leaflet et les applis Mozilla.
Mais cette fois, je reste un peu dubitatif.
Perso, je ne crois pas que WRI soit le lieu pour définir un MVC: C'est un exercice certes stimulant mais long et risqué.
Si on veut appliquer un modèle MVC, il vaut mieux en prendre 1 tout fait avec ses normes de programmation, doc, ...: Zend, Symfony, ... ?
Je n'en ai pas trouvé qui intègre le contrôle d'accès. A moins de partir sur un logiciel de forum (n'en déplaise à Sly, WRI est un forum).

Je ne vais pas médire sur la programmation objet :) mais prend t'on le problème par le bon bout ?
Il vaudrait mieux commencer par une analyse descendante:

1/ WRI et son éco système (somme toutes assez fermé):
* WRI et son application mobile (je crois que c'est de là que vient ton questionnement sur l'API).
* WRI -> Chemineur -> VTTrack -> Peut être 2 ou 3 autres qu'on ne connait pas...

2/ La structure interne de WRI: la souhaite t'on modulaire... et quels sont les modules ?
* Gestion des users et sécurisation des accès
* Fiches
* Forum
* L'appli mobile bien sur
* Séparer base, calcul et présentation ? (== MVC)
* Peut être séparer le service géographique ? (sur la base de /exportations/localisation.php)
* ... liste non exhaustive

3/ A l'intérieur de chaque module, quels sont les objets manipulés ?
* Fiche
* Commentaire
* ...

A ce point, on pourra commencer à parler d'API puisqu'on saura entre quoi et quoi.
La façon de déclarer et de documenter le code objet me semble annexe et venir après.
A propos, connais tu ça: http://php.net/manual/fr/language.oop5.autoload.php (ça aide au rangement du code à un endroit déterministe);

Je suis assez d'accord avec Sly: obtiendra-t-on quelque chose de meilleur après ?
Bref: je suis avec délice vos échanges mais je ne m'y investirai pas, sauf à la fin pour pouvoir assurer la maintenance.
Mais rien ne t'empêche de proposer une implémentation ou un proto.

Bien cordialement.
Avatar du membre
leosw
Messages : 539
Enregistré le : 28 févr. 2013, 17:28
Localisation : Montagne noire

Message par leosw »

Salut à tous les deux,

Effectivement, la seule avancée est que je comprendrais mieux car c'est moi qui l'aurais écrit, mais après lecture des contrôleurs, je pense qu'ils sont facilement réutilisables comme ça. Donc d'accord pour rester comme c'est.

Je n'ai pas saisi si Dominique parlait de l'API, mais je suis pour à 100%. Ne serais-ce que pour montrer l'exemple d'un projet qui permet de partager ces données, et qui pourra perdurer car je pense que les applis nécessitant ce genre de choses vont apparaitre (de nombreux GPS sont maintenant des smartphones, et il serait plaisant d'y voir une couche refuges).

Donc pour moi, je reviens à mon message du Jeu 16 Oct, 2014 6:46 pm

Léo
Avatar du membre
Dominique
Messages : 3704
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

leosw a écrit :Je n'ai pas saisi si Dominique parlait de l'API
Il est vrai que j'ai tout mélangé dans mon commentaire : API, MVC (le sujet de ce fil) et modularité.
L'idée qu'une API est une interface... entre un module et un autre. Or je ne vois qu'un bout du truc: je ne sais pas à qui est destiné l'autre bout ?
leosw a écrit :de nombreux GPS sont maintenant des smartphones, et il serait plaisant d'y voir une couche refuges
ça, c'est diablement intéressant: as tu une idée d'une norme ?
J'avais essayé GML, mais c'est trop complexe pour être répandu.
GeoJson ? (Bien que je n'aime pas le concept d'API basée sur un langage)
Donc la question est : qu'est ce qui est largement utilisable sur des smartphones ?
Avatar du membre
leosw
Messages : 539
Enregistré le : 28 févr. 2013, 17:28
Localisation : Montagne noire

Message par leosw »

Pour moi l'API est destiné à :

* être ouvert dans des librairies (leaflet, openlayer) par nous (mais aussi pour d'autres comme vttrack ou toi si tu ne veux rien modifier, via une simple requête ajax).
* remplacer l'exportation et donc permettre le téléchargement des données sur des appareils pour un mode hors ligne
* être "fetché" par une application (API REST) pour qu'ils puissent avoir une copie en local (exemple chemineur je pense)
* être lu sur des appli mobile qui ne sont pas en HTML (aucune idée de quel format, de comment ça se passe...)[/list]

Pour comparer, un service qui est très similaire à WRI, qui vise le même public et les mêmes applications, c'est geocaching, et leur API (fermée parce que faut faire du fric hein ;) ) est , et il y a pas mal de GPS qui s'en servent (en mode hors ligne)

Voilà ce que j'en pensait pour ma part.