Start

Bonjour bienvenu dans le futur plan de Sohoa. Le but est de définir dans un premier temps les idées de chacun pour développer un mini framework sur la base de Hoa. Rien de bien compliqué au départ, juste un MVC avec quelque Helper bien senti, histoire de lancer le projet.

Je pense qu'on devrait commencer par déterminer la forme globale de notre architecture, à commencer par les composants (si on part sur la base d'une archi orientée composants, ce qui me semble adapté à Hoa). Donc notre question première devrait être comment couvrir :

• le routage
• la contextualisation (comment on gêre l'environement)
• le contrôle
• la sécurité
• l'auditing (voir plus bas)
• la DAO
• les webservices (si on part là dessus)
• la présentation
• la globalisation / internationalisation / inflexion (seulement si on est des warriors)

Tous ces aspects ne sont pas utiles, on peut partir sur une boîte "vide" prennant en charge uniquement les fondamentaux (routage + contrôle + auditing) ou partir sur quelque chose de plus complet (tout en restant simple, inutile d'essayer de concurrencer sf et zf).

Si on veut faire quelque chose d'utile, il faut que ce soit nouveau et original, inutile de reproduire ce qui existe déjà.

Le projet doit-être de type MVC : (pourquoi ?)

M -> \Hoa\Database + \Hoa\Model V -> \Hoa\View : \Hoa\Xyl : Autre C -> \Hoathis\Application (kits de \Hoa\Controller ou surcouche)

Quid du HMVC (Hiérarchique), plus souple à long terme ? (Hoa\Router + Hoa\Dispatcher permet déjà de le faire)

Si on veut vraiment un mini-framework, nos objectifs finaux doivent être :

• la simplicité d'utilisation (require + new + dispatch)
• la rapidité (à la fois de dev et d'exécution)
• la robustess (comme dans n'importe quel framework digne du nom) Le MVC n'est qu'une mode, un framework ne doit, selon moi, pas l'imposer.

Une console ? (vider le cache, initialiser un modèle, ....)

Un framework digne de ce nom dispose d'une couche de routage capable de prendre en charge les modes HTTP et CLI indifférement (j'admet que c'est souvent complexe à mettre en place, faudra formaliser ce besoin). En tout cas avoir deux modes de fonctionnement différents va être rapidement casse-pieds.

Celui-ci devrais comprendre :

• $_this->redirection()

• $_this->rurl() //retourne chemin absolu

• $_this->path() //retourn chemin relatif

• $_this->render() // qui effectuerait le addOverlay + render (pourrait par défaut rendre un overlay du nom de l'action d'ou il est appelé)

• configuration du layout par contrôleur

Une méthode route() pour créer les routes dans un controller et dans la vue (et quid de $this->router->addRule() ?).

Créer des routes dans les contrôleurs ?

Activer \Hoa\Filter et \Hoa\Acl

Regarder à un système de \Hoa\Validator

Générer des squelettes grâce à des commandes simples, par exemple :

• sohoa application myapp // génère une nouvelle app dans le dossier myapp
• sohoa generate controller MyController action1,action2,action3 // génère un contrôleur avec les 3 actions...

...

Une Debug Bar, mais qui dit où est l'erreur et pas simplement 'c'est pas bon' :) dans firefox /chrome & co (ou une popup à part, plus compatible mais moins intégré) ?

Non, il faut prévoir un mécanisme de log/audit/tracing sur le principe d'event dispatcher (ce qui je pense doit être le coeur de tout application moderne, il faut reprendre les bonnes idées du monde JS si possible). Une fois ceci fait, il devient aisé d'ajouter autant de listeners (writers pour les logs / traces) qu'on veut. Je pense notamment à FirePHP, ChromePHP ou tout simplement un writer fichier (note : toutes les exceptions sont déjà balancées sur le canal hoa://Event/Exception et c'est très bien, il faut faire pareil avec les erreurs et les traces ).

Un dossier Vendor pour le Core, les librairies Hoa et les Hoathis

Tout à fait pour, si possible architecturer les composants Hoa pour les rendre installables via Composer.

En paralèlle monter un git et un site + Doc simple mais efficace

Doxygen ?

---

Un exemple d'api est disponible ici : http://wiki.hoa.io/projects:sohoa:api