Surprises pour 2006
Par Laurentj le dimanche, janvier 1 2006, 20:26 - Projets - Lien permanent
Avec Paul et Alain, de l'équipe de Xulfr.org, on s'est fait il y a 2 semaines une petite réunion afin d'établir un plan d'action pour le site xulfr.org. Notre objectif : dynamiser un peu plus la communauté des développeurs XUL, attirer encore plus de monde vers les technologies Mozilla, que ce soit coté développeurs ou coté décideurs. Pour cela, de nombreux changements vont être fait sur le site.
Au niveau technique, certaines de ces nouveautés vont être réalisées avec un tout nouveau framework que je prépare depuis deux mois et demi : Jelix. Il n'y a pas encore de version stable, mais j'y travaille. Il permettra entre autre de réaliser des applications web en XUL. Bien qu'il reprenne certains aspects de Copix, c'est plus qu'un simple fork puisque le coeur est entièrement nouveau. Je reviendrais sur ce sujet plus tard.
Pendant ces premiers mois de 2006 donc, je compte passer la majeure partie de mon temps libre "informatique" (qui n'est pas bien grand) sur le site xulfr.org et Jelix.
En attendant que vous puissiez profiter de ces nouveautés, je vous souhaite à tous une bonne année 2006 :-)
Commentaires
Bonne année et bonne santé !
Plein de moments de bonheur :-)
Amicalement, Monique
Je débute en XUL et je dois dire que c'est assez séduisant comme approche... J'apprécie la facilité avec laquelle on génère l'interface : quelques lignes de XML et hop voici une interface qui surgit du néant :) bluffant ! Les explications sur xulfr.org sont effectivement précieuses. Merci aux travailleurs de l'ombre pour le travail déjà effectué et vivement la suite !
petites suggestions :
Je précise que je ne connais pas vraiment Copix.
J'avais regardé vite fait et puis comme je trouvais ça lourd et manquant de fonctionnalités je n'ai pas regardé plus en profondeur.
Voici donc mes remarques après avoir survolé Jelix.
Trop de choses à déclarer en XML à mon goût. Struts est déjà assez horrible dans ce genre là.
Les trucs basés sur la réflection sont plus simples, comme l'a montré Rails.
Utiliser directement PDO est à mon avis une erreur. Il n'est alors pas possible de se servir de certaines choses dont l'utilisation diffère suivant les SGBDs.
Par exemple, comment gérer les ids ? Les recherches ? Lister les tables et/ou colonnes ? Optimiser avec des LIMIT ?
J'ai vu que pour certaines choses, tu avais fait une classe Outils à part. Pour d'autres, tu as écrit du code en dur dans la classe jDbPDOConnection (avec un code particulièrement laid pour les ids).
Je pense que le plus simple, ce serait tout simplement de garder des classes dépendant du SGBD mais de leur faire utiliser PDO.
Je rappelle que le but de PDO est de proposer un accès unifié aux pilotes, et non pas de faire de l'abstraction de SGBD.
Tout ce qui est "response" ne me semble pas terrible.
Il n'y a pas de gestion générale du protocole HTTP pour buffériser les données de façon appropriée, échanger des entêtes, faire de la négociation de contenu, compresser en gzip et surtout, il n'y a rien pour le cache HTTP.
Éviter de gaspiller de la bande passante me semble pourtant au moins aussi important, si ce n'est plus, que d'éviter de gaspiller des cycles CPU (rôle du cache de code).
Concernant les charsets, je trouve qu'il serait beaucoup plus pertinent de n'utiliser que l'utf-8.
En effet là le code est conçu pour que les chaînes texte contiennent des données dans des charsets arbitraires, et les traitements à appliquer dépendent alors de ces charsets. Mieux vaut tout unifier et faire tous les traitements en sachant qu'il s'agit du charset choisi. Le choix se porte aisément sur un encodage d'Unicode car cela permet de retranscrire tous les caractères possibles.
De nombreuses APIs, comme DOM par exemple, ont déjà choisi de ne fonctionner qu'en unicode pour des soucis d'internationalisation.
Néanmoins les fonctions de traitement des chaînes unicode n'arrivent qu'en PHP6. Il faut donc en attendant coder ses propres fonctions et/ou utiliser iconv si possible.
Omic
C'est un wiki, donc tu peux "eclaircir" :-)
Loufoque:
merci pour tes remarques. Je rappel toutefois que pour l'instant, il n'y a rien de stable, tout est encore en dev, donc faut s'attendre encore à pas mal d'amélioration.
Oui, mais le but, c'est pas de tout écrire à la main. Le but, c'est de pouvoir générer tout ça avec des outils tiers, comme les Jelix-Scripts, ou un eventuel JelixStudio. Il est beaucoup plus facile de manipuler du XML via un outil que de manipuler du PHP.
ouai, m'enfin la reflexion dans PHP, on repassera ;-)... Et puis, ça n'apporte pas forcement que des avantages. Je trouve par exemple que les ActiveRecord de Ror sont un peu trop simpliste, et dés que tu veux faire des choses un peu compliquées, des requêtes compliquées, je trouve que ça devient vite emmerdant à parametrer. Autant écrire la requête directement.
Je n'utilise pas Pdo directement, tu as remarqué qu'il y a une classe qui derive de Pdo.
De plus, tu n'es pas obligé de passer par PDO, mais tu peux utiliser la classe d'abstraction propre à Jelix, permettant alors d'utiliser un "driver", reposant sur les fonctions natives de la base de données.
D'où les classes jdbtools, jDbconnection et ses drivers etc..
Tu n'as pas regardé du coté des DAOs semble-t-il ;-)
J'ai écrit en dur certaines choses pour tenir justement compte des spécificités des bases de données. C'est justement l'interet de ce genre de classe. (vaut mieux faire ça dans jDbPDOConnection que dans ta classe metier non ? ;-) ). Et puis tu remarqueras que jDbPDOConnection derive de PDO. Or je n'ai pas accés aux "drivers" de PDO, et ça ne propose pas tout. Donc les modifications que je fais, je ne peux les faire qu'au niveau de ma classe. D'où le code en dur.
Si tu passes par jDbConnection, alors tout ce qui est specifique à une bdd est dans le driver de la bdd.
C'est une fonction spécifique, qui permet de recupérer un id pour les tables qui n'ont pas d'id en sequence. Pour des tables "normales", il y a la méthode lastInsertId ;-)
Oui mais 1) ce n'est pas terminé et tout ce que tu as dit est prevu. C'est justement pour ça que j'ai fait ces classes reponses. 2) Rien n'empeche pour ton projet de surcharger une classe response existante pour prendre en charge tout tes problèmatiques de cache ;-) (tu la met dans myapp/responses, tu la déclares dans la config, et le tour est joué :-p)
Oui mais il y en a qui preferent utiliser leur propre charset (genre leur base de donnée existante est en iso-machin...). Donc autant proposer le choix. Et puis la gestion de l'utf-8 en PHP, c'est vraiment pas terrible. Quand il utilisera en natif, on verra ça ;-) (et puis iconv est plus que limité pour la manipulation des chaines)
Merci de tes remarques. Si tu en as d'autres, si tu as d'autres idées d'améliorations, je te propose d'en discuter sur la mailing-list, ce sera plus simple (et si tu veux contribuer, y a pas de problème :-) ).
Les configs pleines de xml, on rêve souvent d'avior des outils pour les manupiler, on rêve de faire des outils mais en fin de compte, souvent on les reprend à la main. En plus souvent on veut mettre dans le xml des éléments de config, alors ça a du sens de faire du xml, mais au bout d'un certain temps on réalise que l'on pourrait faire autrement. Ou bien on aimerait avoir la config accessible dans le/les mêmes fichiers que les programmes, ou au moins à portée de main. mes 2centimes (si ça les vaut)
1/ Bonne Année 2006
2/ Attention pas taper :-) L'amateur que je suis se pose une question suscitée par tes prises de positions argumentées concernant AJAX et une alternative possible - bien que limitée à des navigateurs compliant - celle de XUL :
Sachant que Mozilla permet d'afficher des applications XUL alors que Galeon/Epiphany qui sont conçus autour du même moteur d'affichage de documents HTML/XHTML, Gecko en l'occurence, en sont incapables, ne serait il pas possible de créer une librairie/module qui permettrait à ces navigateurs, en compagnie desquels on retrouverait Safari et IE7, de gérer des appli XUL ? Très certainement il y a une très bonne raison pour laquelle cela n'est jamais évoqué, mais qu'elle est elle ? Que leur interface ne soit pas réalisé à partir de XUL est une chose mais pourquoi ne seraient ils pas capable d'afficher/gérer des "documents" XUL si on leur fournit les moyens de le faire comme pour un fichier PDF ?
Est ce Windows/MacOSX ou bien IE7/Safari qui rendraient cette proposition impossible ?
Certes avec un greffon XUL on se retrouverait côté utilisateur avec la même problématique que pour Flash, celle de le télécharger, mais bon, ce serait un début et puis contrairement à Flash, XUL n'est pas propriétaire...
L'utilisation de XUL ou pas dans Epiphany/Galéon et autre navigateur utilisant Gecko, est du bon vouloir des développeurs de ces navigateurs. C'est eux qui décident, lors du développement, de compiler Gecko avec l'option XUL ou pas. Une chose est sûre, on ne peut pas ajouter la prise en charge de XUL aprés coup (genre avec un plugin ou une extension). Son implementation est trop lié au coeur de Gecko.
Cependant, il me semble qu'Epiphany (et Galéon ?) prend en charge XUL. En effet, si mes souvenirs sont bons, Epiphany utilise la bibliothèque Gecko du package Mozilla (en tout cas, c'est le cas dans ubuntu je crois), donc utilise un gecko prenant en charge XUL.
C'est ce que je craignais. Dommage. Reste plus qu'à convaincre Microsoft et Opera à utiliser Gecko ;-)