|
||
|
[intro] Il etait une fois un langage bien sympa qui acceptait sans broncher plein d'erreurs de syntaxe avec des styles differents de codage. Dans le but de developper simplement des applications, ses auteurs avaient réussi a séparer les donnés de la couche de présentation. Ce langage s'appellait php-fi et a bien évulué depuis ce jour. Malheureusement l'utilisation etait devenue trop simple et la saison des bulletins de sécurité approchait avec ses pluies d'annonces. Ce phenomene cybermeteo etait surtout dévastateur pour les produits qui utilisaient "l'image de marque", et ceux qui le consommaient malgré eux ne pouvaient qu'en constater l'effet nefaste sur leur startup. [/intro] PHPLIB est peut etre devenu obsolete depuis que php4 est fourni avec PEAR, mais l'influence de ses methodes est loin d'etre terminée. L'abstraction a tous les niveaux de la circulation des données force les developpeurs auto didactes a adopter des methodes de programmation plus propres tout en permettant une adaptativité qui s'avere etre bien moins limitée que le codage sauvage. PHPLIB est aussi synonyme de portabilité, de sécurité (bien qu'elle ne soit pas prise en charge), et de stabilité (tout au moins au niveau du code). Cadre d'application ------------------- Les problemes soulevés par le manque d'empathie de la part des nouveaux acteurs de cette scene ont rapidement mis a jour des points critiques qui aident a comprendre pourquoi une bonne approches de PHPlib (tout au moins l'acquisition de connaissance semblables) est nécessaire pour maintenir une application web dans un environnement sécurisé sans rester dependant de ses concepteurs. Afin de permettre un developpement simple de l'application, il faut se livrer a un petit exercice qui consiste a utiliser un modele de donnees simple, et une représentation segmentee en differents modules. Application ^ | Templates | Présentation | Formulaires | +--------------- Relations | | Table Proxy | Données | Source de données v Interaction entre les modules individuels. ------------------------------------------ Source de donnees L'accès aux données est originalement définie sur une interface choisie arbitrairement selon les ressources locales (ex:DB_Sql). Le serveur web peut aussi etre la source de donnees, puisqu'il nourrit formulaires (Get, Post, Cookie) Table Proxy La TABLE_PROXY permet d'abstraire les donnees de la requete sur la source et joue egalement le role de containeur pour ces memes donnees. Son role est similaire a celui du xml pour le html par la structure qu'elle fournit aux données qu'elle contient. Relations On construit les relations entre les différentes données sur le module de relations. L'utilisation de metadonnées est rendue possible a ce niveau la (ex : Foreign Key). A partir de cette couche on peut dire que toutes les données ont été COMPLETEMENT abstraites, de facon a produire au moment approprié une interface simple, agréable, fonctionnelle et répondante. Formulaires / Templates / Application Les formulaires (OOH/IXT voir les deux modules PHPLIB) operent l'abstraction des champs (input) de l'interface. Ce qui en ressort est également exporté en direction des templates, puis vers le html. Il est aussi possible d'utiliser XSLT a ces niveaux. Chaque niveau reste indépendant de l'autre et peut etre utilisé séparément du moment que les interfaces auxquelles il s'attache sont définies en conséquence. Circulation des données ----------------------- La modélisation des données est produite au moyen du module de relation et se base sur la table_proxy (qui représente le conteneur de données). Ces données peuvent etre présentées par l'interface, puis de l'interface renvoyées vers leur origine. Le retour des données prend place a l'interieur du module de relation qui garantit la cohérence entre les différents champs utilisés. Le réexamen des différentes zones de données règle le Proxy, puisque chaque champ est évalué par les fonctions correspondantes (check_row..). Le Proxy par définition ne connaît pas le lien entre les données, cette tâche appartenant au module de relation, toutefois il garantit sa validité par le format des données qu'il traite. Le processus comp;et de traitement prend donc place ici. La présentation des donnees etant prise en charge dans le module formulaire et le module template, on peut donc etendre le diagramme de depart comme suit: Application ^ Circulation des données | Templates | SORTIE | Formulaires | | ------------- Relations | TRAITEMENT | ------------- Table Proxy | | ENTREE Source de données | Problemes et solutions : ------------------------ Il faut noter qu'aucune des couches n'anticipe sur la couche suivante, partant du principe que le bloc suivant s'en occupera (notion d'heritage). Cette situation peut etre genante lors de l'integration d'applications deja complexes, mais elle a le mérite de forcer la route du developpement vers des methodes de codage plus sécurisées et plus stables. Il existe certaines dépendances entre les modules, en ce qui concerne les données : la Table_Proxy doit vérifier les champs avant de les passer les formulaires peuvent avoir a fournir du JS les relations entre champs doivent etre clarifiées au niveau des dependances Cette variante impose une modélisation externe des données, de sorte que les contrôles correspondants puissent devenir automatiques. L'utilisation des templates d'un coté et de l'abstraction des formulaires de l'autre peut pousser a confondre ces deux couches au point d'en abandonner une au profit de l'autre sous pretexte de redondance. Cela ne fait que souligner le besoin réel d'un nouveau format intermediaire entre la couche relation et la couche application : on devrait recourir au xml comme méthode préférée, de sorte que de toutes les couches superieures bénéficient d'un accès simple au couches internes et ainsi abstraire completement le contenu logique. |
||
|