2004-07-28 13:07:39 UTC
On est bien d'accord donc que nous sommes les seuls à avoir publié du code pour cette fonctionnalité pour l'instant.
Je reprends vos points un par un. L'étiquette d'un professionnel du développement Internet lui dicte à ce que je sache de se présenter lui et la société qu'il représente pour que tout le monde puisse savoir qui sont les personnes qui s'intéressent à ce développement à moins que cette étiquette ne s'applique pas dans votre cas.
Je suis désolé. Traitement modulaire des erreurs est pour nous assez clair. Je me permets de vous rappeler que la pièce la plus importante d'un système informatique est sa façon de traiter les erreurs pour que les personnes physiques qui ont en charge ce système puisse être notifiées correctement de l'état du système pour pouvoir réagir en conséquence. Ce que la formule que vous n'avez pas comprit signifie est le fait que le module rassemble le traitement des erreurs dans un seul bloc qui peut être ensuite parfaitement intégré au sein d'un système de traitement des erreurs plus générique, comme celui d'une application de gestion de contenu par exemple.
Vous avez loupé un épisode et c'est celui du cache pour le contenu compilé.
Intégration des données locales. Le module peut déjà faire en sorte que cette intégration soit sélective dans le sens ou vous pouvez avoir sur une même page une ressource PJ et une ressource locale avec un URL personnalisable si le portail ne déclare qu'une seule ressource pour la page. Vous pouvez voir un exemple de cette utilisation à l'adresse suivante
http://www.mairie12.paris.fr/index.php/mairie12/generic.php?s=sp.tpl&xml=F1652.xml&xsl=Fiche.xsl, en bas de la page. Nous voulons amener ce développement à ce qu'il apporte un maximum de facilité dans l'utilisation des données locales et à terme, un API très simple pour la construction des informations qui seront remontées à des services supérieurs selon les standards XML existants. Tout cela demande un peu plus de 100 lignes de code.
Je vous laisse élucider si cela rime ou pas mais je considère 700 lignes de code à peine comme un début de développement respectable et surtout pas comme quelque chose de "complexe". Nous n'avons peut être pas les mêmes normes en ce qui concerne la complexité d'une composante logicielle par contre.
En ce qui concerne les "simples" appels aux fonctions XSL de PHP, ils sont simples certes mais cela seulement après que vous ayez recompilé PHP avec le support pour cette extension et peut être même la bibliothèque XSLT requise. Ce module utilise le scénario le plus simple possible pour les utilisateurs tout en se concentrant sur l'intégration d'autres moteurs XSLT par la suite. Nous n'imposons aucune modification de l'environnement PHP d'exécution.
Vous avez choisi de toujours vérifier la date de modification des fichiers. Nous avons choisi de laisser la possibilité de configuration de cet aspect aux utilisateurs.
En ce qui concerne l'intégration du contenu XML compilé dans les pages, j'espère que vous n'êtes pas sérieux sur l'absence du JS dans le navigateur. J'ai nullement envie de discuter sur cette liste de Lynx dans les prochains messages surtout quand on sait que la dynamique côté client jouera un rôle de plus en plus important et sûrement pas l'inverse. Mais pour revenir, tout d'abord l'architecture du module fait que le traitement se fait par étapes et dans l'une des étapes le module peut fournir le contenu HTML brut, prêt à être intégré dans une page côté serveur.
Deuxièmement, je viens de faire des tests dans Internet Exploreur et des erreurs JS n'empêchent pas du tout le bloc JS de ce module de s'exécuter et donc malgré la notification d'erreur, le contenu XML s'affiche parfaitement bien. D'ailleurs les erreurs JS d'une page ont exactement la même classe que les bugs d'Exploreur ou Windows ou n'importe quelle composante logicielle et pour l'instant je ne connais que Microsoft qui code leur logiciels pour s'adapter aux bugs des applications qui tournent dessus.
Et troisièmement, je me permet de vous informer que les systèmes d'accessibilité vraiment professionnels utilisent le DOM client final pour les rendus et les transformations donc la construction de la page est transparente, qu'elle soit faite côté client ou serveur.
Finalement en ce qui concerne votre description du code développé par vous, je suis persuadé que vous êtes un champion des regex et des one-liners Perl, et que vous auriez pu tout faire différemment. Je vous félicite.
Bref, je ne vois plus aucun intérêt de continuer cette discussion puisque nous ne parlons visiblement pas du tout de la même chose. Vous parlez d'un quick hack de quelques lignes qui rentre dans un environnement très bien contrôlé et connu et qui doit être lu, comprit et changé au niveau du code pour s'adapter à n'importe quel autre environnement extérieur. Nous nous dirigeons vers une vraie bibliothèque modulaire et documentée, la plus indépendante de l'environnement possible, testée en situations de charge réelle et ayant un API clair et standard pour l'intégration dans n'importe quelle architecture.
Pour être plus clair, c'est la différence entre un script shell qui tourne sur une machine bien connue et configuré et une application à base de "configure".
Nous nous réservons le droit de ne plus poursuivre cette discussion si vous ne considérez pas qu'il est nécessaire de se présenter et si les réponses n'apporterons aucun aspect réellement constructif à ce projet.
Cordialement,
Daniel BODEA,
BYS Promotion
Internet Services
