Voici les gros chantiers qu'il serait bon d'engager, pour les futures versions de Jelix. Ceux que je vais citer sont possibles, je pense, dans la serie des jelix 1.x (donc pour les futures versions 1.4, 1.5 etc), car cela ne va pas casser les modules existants à mon avis (ou en tout cas, la transition sera douce).
Donc pour une 1.4 et suivante, voici ce que je propose. Tout commentaire est le bienvenu. (pour discuter des solutions proposées aux différents problèmes, ouvrez plutôt des nouvelles discussions)
1) amélioration de l'architecture du core, pour diminuer les dépendances entre classes, afin de favoriser l'autoload, ou l'utilisation individuelle des composants. Un exemple :
- suppression des variables globales gJCoord et gJConfig, et remplacement par des jApp::coord() et jApp::config(). Pour des raisons de compatibilité, il y aurait tout de même gJCoord et gJConfig mais seraient marqué déprécié. Ce matin dans le train, j'ai commencé jApp::config(). - J'ai fait aussi jApp::loadConfig() : ce n'est plus jCoordinator qui lance le chargement de la config. Cela permettra de charger un "environnement" jelix sans utiliser jCoordinator. (là encore j'ai fait en sorte que ça reste compatible avec du vieux code)
2) autoload - ajout d'une classe autoload pour supporter la specification PSR-0 (c'est fait dans une de mes branches) - permettre aux modules de déclarer des mappings ou un autoloader
3) suppression du système de moteurs d'URL Ce système de moteurs d'URL pose trop de problème, surtout quand il y a plusieurs entrypoints qui utilisent des moteurs différents. De plus, cela complexifie la configuration. les moteurs "simple" et "basic_significant" ont beau être performants et simples au niveau code, leur configuration devient compliquée, dés lors que l'on a plusieurs points d'entrée, du support https etc (voir la conf et les nombreuses questions à ce sujet dans le forum)
Les instances sont stockées en session. On fini par avoir en session des dizaines de formulaires. Chargement lourd au final, et pour rien en plus (en général, une action ne traite qu'un formulaire à la fois). De plus, il y a parfois des soucis pour récupérer l'instance d'un formulaire (session timeout par exemple).
9) jDb : terminer jDbTools -> cela facilitera les scripts d'installation. Utilisation d'une API abstraite plutôt que de fournir un script SQL pour chaque type de base (quand il y en a un pour toutes les bases...). on pourra aussi générer une table en base à partir d'un DAO avec ça
10) jDb : driver mysqli / utilisation d'une API récente de mysql.
11) migration de tout les tests vers PHPUnit. (ou Atoum ?)
12) paquet pear de Jelix + paquets pear de certains modules externes + site pear.jelix.org
D'autres chantiers ?
A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de versions avant un an voir plus... (sauf si on s'y met tous, peut être que... ;-) )
Malgr mon silence et ma prise de distance le projet, par manque de temps, je n'en reste pas moins un utilisateur actif et je continue de suivre ce projet qui me tient c ur.
Je n'ai pas r agi aux derniers changes de la ML mais me revoil , au moins pour discuter des volutions.
Le 11/01/2012 13:54, Laurent Jouanneau a crit :
> Bonjour,
> Voici les gros chantiers qu'il serait bon d'engager, pour les futures > versions de Jelix. Ceux que je vais citer sont possibles, je pense, > dans la serie des jelix 1.x (donc pour les futures versions 1.4, 1.5 > etc), car cela ne va pas casser les modules existants mon avis (ou > en tout cas, la transition sera douce).
Tant que le "cassage" est document , mis en vidence et qu'on fourni les cl s pour adapter le code existant, a n'est pas trop g nant mon avis. Surtout du moment qu'il s'agit de mises jour majeures (et non des X.y.z).
> Donc pour une 1.4 et suivante, voici ce que je propose. Tout > commentaire est le bienvenu. (pour discuter des solutions propos es > aux diff rents probl mes, ouvrez plut t des nouvelles discussions)
Je suppose que la num rotation n'est pas li e un ordre de priorit s ?
> 1) am lioration de l'architecture du core, pour diminuer les > d pendances entre classes, afin de favoriser l'autoload, ou > l'utilisation individuelle des composants. Un exemple :
> - suppression des variables globales gJCoord et gJConfig, et > remplacement par des jApp::coord() et jApp::config(). Pour des raisons > de compatibilit , il y aurait tout de m me gJCoord et gJConfig mais > seraient marqu d pr ci . Ce matin dans le train, j'ai commenc > jApp::config().
Je passe certainement c t de cet exemple dans le fait qu'il illustre "la diminution des d pendances entre classes ou l'utilisation individuelle des composants" ? part wrapper l'acc s aux deux variables globales, il y a un int r t plus conceptuel ? (Ceci dit, j'aime bien l'id e)
> - J'ai fait aussi jApp::loadConfig() : ce n'est plus jCoordinator qui > lance le chargement de la config. Cela permettra de charger un > "environnement" jelix sans utiliser jCoordinator. (l encore j'ai fait > en sorte que a reste compatible avec du vieux code)
C'est en effet une am lioration non n gligeable qui ouvre la porte des chargements d'environnements :)
> 2) autoload > - ajout d'une classe autoload pour supporter la specification PSR-0 > (c'est fait dans une de mes branches) > - permettre aux modules de d clarer des mappings ou un autoloader
> 3) suppression du syst me de moteurs d'URL > Ce syst me de moteurs d'URL pose trop de probl me, surtout quand il y > a plusieurs entrypoints qui utilisent des moteurs diff rents. > De plus, cela complexifie la configuration. les moteurs "simple" et > "basic_significant" ont beau tre performants et simples au niveau > code, leur configuration devient compliqu e, d s lors que l'on a > plusieurs points d'entr e, du support https etc (voir la conf et les > nombreuses questions ce sujet dans le forum)
Si on arrive faire une transition en douceur qui ne casse pas trop d'appli ou ne demande pas trop de travail aux d veloppeurs, c'est une tr s bonne id e. C'est peut- tre la mise jour la plus critique de la roadmap de 1.x, voir donc quand on voudrait y caser.
> 4) jAuth : am lioration pour la prise en charge des authentifications > d port es (oAuth, OpenId etc).
Am liorer jAuth ne peut qu' tre une bonne id e :)
> 5) am liorations pour faciliter la prise en charge de diff rents > environnement : production, dev, test etc..
> Les instances sont stock es en session. On fini par avoir en session > des dizaines de formulaires. Chargement lourd au final, et pour rien > en plus (en g n ral, une action ne traite qu'un formulaire la fois). > De plus, il y a parfois des soucis pour r cup rer l'instance d'un > formulaire (session timeout par exemple).
jForms est d j bien pratique mais souffre en effet de ces petits probl mes. Tout ce qui vise l'am liorer est forc ment mettre dans une roadmap.
> 9) jDb : terminer jDbTools -> cela facilitera les scripts > d'installation. Utilisation d'une API abstraite plut t que de fournir > un script SQL pour chaque type de base (quand il y en a un pour toutes > les bases...). on pourra aussi g n rer une table en base partir d'un > DAO avec a
Bonne id e :)
> 10) jDb : driver mysqli / utilisation d'une API r cente de mysql.
pas forc ment urgent je pense, mais caser dans 1.x est une bonne id e.
> 11) migration de tout les tests vers PHPUnit. (ou Atoum ?)
simpletest devra tre totalement remplac . Je pense qu'on doit tous tre plus ou moins d'accord sur ce point. Migrer vers PHPunit ou Atoum... il faudra en discuter. Simpletest nous a chaud mais a ne doit pas (trop) jouer dans les crit res du choix.
> 12) paquet pear de Jelix + paquets pear de certains modules externes + > site pear.jelix.org
C'est plut t ind pendant du dev pur du framework, donc caser quand on peut. Est-ce qu'on a d j discut de mettre des phar disposition galement ?
> D'autres chantiers ?
Je vais y r fl chir mais a me semblerait d j tre une jolie roadmap vers 2.0
> A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule > directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de > versions avant un an voir plus... (sauf si on s'y met tous, peut tre > que... ;-) )
Il faut 1.4, 1.5, 1.6, ... on a d j fait les frais d'une roadmap trop longue sans les moyens qui vont avec. La seule probl matique dans ce cas est la gestion des versions de maintenance. Il faudrait voir la politique qu'on voudrait adopter (mais li e finalement aux moyens disponibles).
Je sais que c'est facile mais "release early, release often" ;)
Encore merci pour cette mise plat des gros chantiers venir.
Pour ma part j'aurai bien parlé de trois "petites" choses :
1) l'ORM : mais j'ai plusieurs réticences. Même si DAO se fait vieux (il parait ;) il fait son boulot et jDb en renfort aussi. Après changer pour quoi ? une solution existante ou "home made" ? J'aurai bien aimé voir le "query builder" de torgan en branle par exemple pour se faire une idée ;)
2) Framework JS Etre en mesure, par configuration, de choisir le framework qu'on veut . Aujourd'hui jelix est "marié" à jQuery mais pourquoi pas d'autres style YUI (coucou Hadrien ;) qui lui aussi à fait un "portage" pour jForms avec ce dernier.
3) HTML5 il y a un ticket sur le sujet mais ce n'est pas anodin je pense et ne se limite pas à changer que le prologue pour en faire ;-)
A cheval entre html5/framework js il y a TwitterBootstrap (exploitant jQuery et un system de grille pas loin deu 960gs) et d'autres que je n'ai pas testé qui peuvent apportés un +
Divers : Sinon à l'allure où on va dans nos idées je nous vois mal les produire sur la branche v1.x surtout comme le souligne Loïc quant aux ressources en face "des" chantiers.
Olivier
Le 11 janvier 2012 15:08, Loic Mathaud <l...@mathaud.net> a écrit :
> Malgré mon silence et ma prise de distance le projet, par manque de > temps, je n'en reste pas moins un utilisateur actif et je continue de > suivre ce projet qui me tient à cœur.
> Je n'ai pas réagi aux derniers échanges de la ML mais me revoilà, au > moins pour discuter des évolutions.
> Le 11/01/2012 13:54, Laurent Jouanneau a écrit : > > Bonjour,
> > Voici les gros chantiers qu'il serait bon d'engager, pour les futures > > versions de Jelix. Ceux que je vais citer sont possibles, je pense, > > dans la serie des jelix 1.x (donc pour les futures versions 1.4, 1.5 > > etc), car cela ne va pas casser les modules existants à mon avis (ou > > en tout cas, la transition sera douce).
> Tant que le "cassage" est documenté, mis en évidence et qu'on fourni les > clés pour adapter le code existant, ça n'est pas trop gênant à mon avis. > Surtout du moment qu'il s'agit de mises à jour majeures (et non des X.y.z).
> > Donc pour une 1.4 et suivante, voici ce que je propose. Tout > > commentaire est le bienvenu. (pour discuter des solutions proposées > > aux différents problèmes, ouvrez plutôt des nouvelles discussions)
> Je suppose que la numérotation n'est pas liée à un ordre de priorités ?
> > 1) amélioration de l'architecture du core, pour diminuer les > > dépendances entre classes, afin de favoriser l'autoload, ou > > l'utilisation individuelle des composants. Un exemple :
> > - suppression des variables globales gJCoord et gJConfig, et > > remplacement par des jApp::coord() et jApp::config(). Pour des raisons > > de compatibilité, il y aurait tout de même gJCoord et gJConfig mais > > seraient marqué déprécié. Ce matin dans le train, j'ai commencé > > jApp::config().
> Je passe certainement à côté de cet exemple dans le fait qu'il illustre > "la diminution des dépendances entre classes ou l'utilisation > individuelle des composants" ? > À part wrapper l'accès aux deux variables globales, il y a un intérêt > plus conceptuel ? > (Ceci dit, j'aime bien l'idée)
> > - J'ai fait aussi jApp::loadConfig() : ce n'est plus jCoordinator qui > > lance le chargement de la config. Cela permettra de charger un > > "environnement" jelix sans utiliser jCoordinator. (là encore j'ai fait > > en sorte que ça reste compatible avec du vieux code)
> C'est en effet une amélioration non négligeable qui ouvre la porte à des > chargements d'environnements :)
> > 2) autoload > > - ajout d'une classe autoload pour supporter la specification PSR-0 > > (c'est fait dans une de mes branches) > > - permettre aux modules de déclarer des mappings ou un autoloader
> > 3) suppression du système de moteurs d'URL > > Ce système de moteurs d'URL pose trop de problème, surtout quand il y > > a plusieurs entrypoints qui utilisent des moteurs différents. > > De plus, cela complexifie la configuration. les moteurs "simple" et > > "basic_significant" ont beau être performants et simples au niveau > > code, leur configuration devient compliquée, dés lors que l'on a > > plusieurs points d'entrée, du support https etc (voir la conf et les > > nombreuses questions à ce sujet dans le forum)
> Si on arrive à faire une transition en douceur qui ne casse pas trop > d'appli ou ne demande pas trop de travail aux développeurs, c'est une > très bonne idée. > C'est peut-être la mise à jour la plus critique de la roadmap de 1.x, à > voir donc quand on voudrait y caser.
> > 4) jAuth : amélioration pour la prise en charge des authentifications > > déportées (oAuth, OpenId etc).
> Améliorer jAuth ne peut qu'être une bonne idée :)
> > 5) améliorations pour faciliter la prise en charge de différents > > environnement : production, dev, test etc..
> > 7) jForms: améliorer le stockage des instances
> > Les instances sont stockées en session. On fini par avoir en session > > des dizaines de formulaires. Chargement lourd au final, et pour rien > > en plus (en général, une action ne traite qu'un formulaire à la fois). > > De plus, il y a parfois des soucis pour récupérer l'instance d'un > > formulaire (session timeout par exemple).
> jForms est déjà bien pratique mais souffre en effet de ces petits > problèmes. Tout ce qui vise à l'améliorer est forcément à mettre dans > une roadmap.
> > 9) jDb : terminer jDbTools -> cela facilitera les scripts > > d'installation. Utilisation d'une API abstraite plutôt que de fournir > > un script SQL pour chaque type de base (quand il y en a un pour toutes > > les bases...). on pourra aussi générer une table en base à partir d'un > > DAO avec ça
> Bonne idée :)
> > 10) jDb : driver mysqli / utilisation d'une API récente de mysql.
> pas forcément urgent je pense, mais à caser dans 1.x est une bonne idée.
> > 11) migration de tout les tests vers PHPUnit. (ou Atoum ?)
> simpletest devra être totalement remplacé. Je pense qu'on doit tous être > plus ou moins d'accord sur ce point. > Migrer vers PHPunit ou Atoum... il faudra en discuter. Simpletest nous a > échaudé mais ça ne doit pas (trop) jouer dans les critères du choix.
> > 12) paquet pear de Jelix + paquets pear de certains modules externes + > > site pear.jelix.org
> C'est plutôt indépendant du dev pur du framework, donc à caser quand on > peut. > Est-ce qu'on a déjà discuté de mettre des phar à disposition également ?
> > D'autres chantiers ?
> Je vais y réfléchir mais ça me semblerait déjà être une jolie roadmap > vers 2.0
> > A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule > > directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de > > versions avant un an voir plus... (sauf si on s'y met tous, peut être > > que... ;-) )
> Il faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop > longue sans les moyens qui vont avec. > La seule problématique dans ce cas est la gestion des versions de > maintenance. Il faudrait voir la politique qu'on voudrait adopter (mais > liée finalement aux moyens disponibles).
> Je sais que c'est facile mais "release early, release often" ;)
> Encore merci pour cette mise à plat des gros chantiers à venir.
Le 11 janvier 2012 15:08, Loic Mathaud <l...@mathaud.net> a écrit :
> Le 11/01/2012 13:54, Laurent Jouanneau a écrit : >> Donc pour une 1.4 et suivante, voici ce que je propose. Tout >> commentaire est le bienvenu. (pour discuter des solutions proposées >> aux différents problèmes, ouvrez plutôt des nouvelles discussions)
> Je suppose que la numérotation n'est pas liée à un ordre de priorités ?
>> 1) amélioration de l'architecture du core, pour diminuer les >> dépendances entre classes, afin de favoriser l'autoload, ou >> l'utilisation individuelle des composants. Un exemple :
>> - suppression des variables globales gJCoord et gJConfig, et >> remplacement par des jApp::coord() et jApp::config(). Pour des raisons >> de compatibilité, il y aurait tout de même gJCoord et gJConfig mais >> seraient marqué déprécié. Ce matin dans le train, j'ai commencé >> jApp::config().
> Je passe certainement à côté de cet exemple dans le fait qu'il illustre > "la diminution des dépendances entre classes ou l'utilisation > individuelle des composants" ? > À part wrapper l'accès aux deux variables globales, il y a un intérêt > plus conceptuel ? > (Ceci dit, j'aime bien l'idée)
après reflexion, non, effectivement ça ne resoud pas le problème des dépendances. Par contre ça fait du code plus propre. L'objectif ici de config() etc en fait est de faire de jApp le centre de l'environnement Jelix.
>> - J'ai fait aussi jApp::loadConfig() : ce n'est plus jCoordinator qui >> lance le chargement de la config. Cela permettra de charger un >> "environnement" jelix sans utiliser jCoordinator. (là encore j'ai fait >> en sorte que ça reste compatible avec du vieux code)
> C'est en effet une amélioration non négligeable qui ouvre la porte à des > chargements d'environnements :)
Tout à fait :-) Par ex, lors de la lecture de la config, plus tard, il se chargera de mettre en place l'autoload. Après, on fera ce qu'on voudra : jCoordinator + jRequest ou autre chose.
>> 3) suppression du système de moteurs d'URL >> Ce système de moteurs d'URL pose trop de problème, surtout quand il y >> a plusieurs entrypoints qui utilisent des moteurs différents. >> De plus, cela complexifie la configuration. les moteurs "simple" et >> "basic_significant" ont beau être performants et simples au niveau >> code, leur configuration devient compliquée, dés lors que l'on a >> plusieurs points d'entrée, du support https etc (voir la conf et les >> nombreuses questions à ce sujet dans le forum)
> Si on arrive à faire une transition en douceur qui ne casse pas trop > d'appli ou ne demande pas trop de travail aux développeurs, c'est une > très bonne idée. > C'est peut-être la mise à jour la plus critique de la roadmap de 1.x, à > voir donc quand on voudrait y caser.
Le point le plus critique que je vois, c'est pour ceux qui ont mis des urls en dur dans leurs templates. Si ils étaient en "simple", forcément, ils vont devoir retoucher tout leurs templates impactés. Ceux par contre qui ont utilisé jurl, je ne pense pas que ça changera grand chose. Ceux qui étaient en simple ou basic_significant, auront juste à faire un urls.xml avec une balise url qui va bien utilisant les paramètres réservés _module, _controller et _method, comme je le propose dans la RFC. (une seule balise url par entrypoint pour toute l'appli sera possible). Mais à la limite, c'est le genre de truc que jelix peut faire automatiquement lors de la mise à jour.
Et sinon je ne vois pas d'autres soucis pour le moment.
>> 10) jDb : driver mysqli / utilisation d'une API récente de mysql.
> pas forcément urgent je pense, mais à caser dans 1.x est une bonne idée.
Il me semble que les fonctions mysql que l'on utilise sont dépréciées dans PHP, ou un truc comme ça. ça devient urgent donc...
>> 11) migration de tout les tests vers PHPUnit. (ou Atoum ?)
> simpletest devra être totalement remplacé. Je pense qu'on doit tous être > plus ou moins d'accord sur ce point.
oui, Pierrick vient d'annoncer que simpletest n'évoluera plus. juste du bugfix. Il faut donc effectivement le virer. Avec le futur autoload, on pourra toutefois le mettre dans un module et proposer celui-ci sur booster.
> Migrer vers PHPunit ou Atoum... il faudra en discuter. Simpletest nous a > échaudé mais ça ne doit pas (trop) jouer dans les critères du choix.
Atoum semble avoir fait bonne presse parmi ceux qui sont allés au PHPTour. Il est devenu un bon challenger apparement. Le souci d'Atoum, c'est qu'il faut du PHP 5.3 minimum donc on ne pourra pas tester Jelix sur du 5.2. à voir si sur une 1.x, on vire le support 5.2 ou pas (j'aurais préféré faire ça sur une 2.0). Autre souci d'Atoum : la doc. Mais ça va s'arranger je pense.
>> 12) paquet pear de Jelix + paquets pear de certains modules externes + >> site pear.jelix.org
> C'est plutôt indépendant du dev pur du framework, donc à caser quand on > peut. > Est-ce qu'on a déjà discuté de mettre des phar à disposition également ?
j'avais ouvert un ticket il y a longtemps. Il faut étudier la compatibilité des sources de jelix pour les mettre dans un Phar (au niveau des chemins etc...).
>> D'autres chantiers ?
> Je vais y réfléchir mais ça me semblerait déjà être une jolie roadmap > vers 2.0
>> A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule >> directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de >> versions avant un an voir plus... (sauf si on s'y met tous, peut être >> que... ;-) )
> Il faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop > longue sans les moyens qui vont avec.
Oui mais maintenant, je developpe dans des branches, et dans master il n'y a que des trucs terminés :-) Donc en theorie, on peut release quand on veut à partir de master. Ce qui n'était pas le cas pour la 1.2 par exemple ou j'avais longtemps laissé le trunk en chantier, pas stable.
> La seule problématique dans ce cas est la gestion des versions de > maintenance. Il faudrait voir la politique qu'on voudrait adopter (mais > liée finalement aux moyens disponibles).
> Je sais que c'est facile mais "release early, release often" ;)
> > 3) suppression du système de moteurs d'URL
>> > Ce système de moteurs d'URL pose trop de problème, surtout quand il y
>> > a plusieurs entrypoints qui utilisent des moteurs différents.
>> > De plus, cela complexifie la configuration. les moteurs "simple" et
>> > "basic_significant" ont beau être performants et simples au niveau
>> > code, leur configuration devient compliquée, dés lors que l'on a
>> > plusieurs points d'entrée, du support https etc (voir la conf et les
>> > nombreuses questions à ce sujet dans le forum)
>> Si on arrive à faire une transition en douceur qui ne casse pas trop
>> d'appli ou ne demande pas trop de travail aux développeurs, c'est une
>> très bonne idée.
>> C'est peut-être la mise à jour la plus critique de la roadmap de 1.x, à
>> voir donc quand on voudrait y caser.
> Perso j'ai uniquement utilisé le moteur "significant". J'ai activé les
autres uniquement car je galère à chaque fois pour virer le index.php en utilisant un vhost.
>> > 4) jAuth : amélioration pour la prise en charge des authentifications
>> > déportées (oAuth, OpenId etc).
>> Améliorer jAuth ne peut qu'être une bonne idée :)
> Je suis sur ce sujet, particulièrement la gestion de oAuth. Avec oAuth on
aura la gestion de tout les services sociaux (FB/G+/Twitter/LinkedIn/...), je pense que jelix ne peux plus s'en passer.
> > 8) jForms: plugins pour générer des contrôles personnalisés.
>> jForms est déjà bien pratique mais souffre en effet de ces petits
>> problèmes. Tout ce qui vise à l'améliorer est forcément à mettre dans
>> une roadmap.
> Je me suis aussi lancé dans le ticket 1072. J'en ai énormément besoin,
donc je pense que j'arriverai à fournir une branche à fusionner "assez rapidement".
> > D'autres chantiers ?
> Supprimer la gestion d'autres charset qu'UTF-8. Pas forcément dur à faire,
et ça simplifie l'utilisation du framework.
> > A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule
>> > directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de
>> > versions avant un an voir plus... (sauf si on s'y met tous, peut être
>> > que... ;-) )
>> Il faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop
>> longue sans les moyens qui vont avec.
>> La seule problématique dans ce cas est la gestion des versions de
>> maintenance. Il faudrait voir la politique qu'on voudrait adopter (mais
>> liée finalement aux moyens disponibles).
> Je pense aussi qu'il faut y aller en petite version... Surtout que ça
donne une vitalité au projet.
Peut être gérer en time release de 3 mois ? Ca donne une vitalité au projet, ca force à avancer dans le projet et ca permet de gérer les fenêtres de merge.
Le 11 janvier 2012 15:32, FoxMaSk <foxm...@gmail.com> a écrit :
> Bonjour,
> Pour ma part j'aurai bien parlé de trois "petites" choses :
> 1) l'ORM : > mais j'ai plusieurs réticences. > Même si DAO se fait vieux (il parait ;) il fait son boulot et jDb en renfort > aussi. > Après changer pour quoi ? une solution existante ou "home made" ? > J'aurai bien aimé voir le "query builder" de torgan en branle par exemple > pour se faire une idée ;)
On pourrait essayer de faire évoluer jDao pour pouvoir faire des jointures n-n (mais je ne sais pas encore vraiment comment).
> 2) Framework JS > Etre en mesure, par configuration, de choisir le framework qu'on veut . > Aujourd'hui jelix est "marié" à jQuery mais pourquoi pas d'autres style YUI > (coucou Hadrien ;) qui lui aussi à fait un "portage" pour jForms avec ce > dernier.
Dans l'absolu, rien n'empêche d'utiliser autre chose. actuellement, y en définive juste le builder par défaut de jForms qui utilise jQuery. Si tu veux autre chose, fait un autre builder (qui sont des plugins). Donc par configuration, c'est simple : dans {form}, indique ton builder.
> 3) HTML5 > il y a un ticket sur le sujet mais ce n'est pas anodin je pense et ne se > limite pas à changer que le prologue pour en faire ;-)
Il faut faire les travaux prévus sur jforms avant en fait. Cela facilitera les choses ensuite.
Mais oui, faut l'ajouter comme chantier : une réponse HTML5 + builder jforms optimisé pour HTML5.
> Divers : > Sinon à l'allure où on va dans nos idées je nous vois mal les produire sur > la branche v1.x surtout comme le souligne Loïc quant aux ressources en face > "des" chantiers.
tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, n'est-ce pas ?
> > Divers : > > Sinon à l'allure où on va dans nos idées je nous vois mal les produire > sur > > la branche v1.x surtout comme le souligne Loïc quant aux ressources en > face > > "des" chantiers.
> tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, n'est-ce > pas ?
Non je disais bien sur la branche 1.x Je nous vois pas produire tout cela sur la branche 1.x, vue les forces en présences de la tâche qui n'est pas annodine ou bien alors en découpant très finement ce qui ferait l'objet de chq petite version. genre une version une feature ?
>>> > 3) suppression du système de moteurs d'URL >>> > Ce système de moteurs d'URL pose trop de problème, surtout quand il y >>> > a plusieurs entrypoints qui utilisent des moteurs différents. >>> > De plus, cela complexifie la configuration. les moteurs "simple" et >>> > "basic_significant" ont beau être performants et simples au niveau >>> > code, leur configuration devient compliquée, dés lors que l'on a >>> > plusieurs points d'entrée, du support https etc (voir la conf et les >>> > nombreuses questions à ce sujet dans le forum)
>>> Si on arrive à faire une transition en douceur qui ne casse pas trop >>> d'appli ou ne demande pas trop de travail aux développeurs, c'est une >>> très bonne idée. >>> C'est peut-être la mise à jour la plus critique de la roadmap de 1.x, à >>> voir donc quand on voudrait y caser.
> Perso j'ai uniquement utilisé le moteur "significant". J'ai activé les > autres uniquement car je galère à chaque fois pour virer le index.php en > utilisant un vhost.
>>> > 4) jAuth : amélioration pour la prise en charge des authentifications >>> > déportées (oAuth, OpenId etc).
>>> Améliorer jAuth ne peut qu'être une bonne idée :)
> Je suis sur ce sujet, particulièrement la gestion de oAuth. Avec oAuth on > aura la gestion de tout les services sociaux (FB/G+/Twitter/LinkedIn/...), > je pense que jelix ne peux plus s'en passer.
>>> > 8) jForms: plugins pour générer des contrôles personnalisés.
>>> jForms est déjà bien pratique mais souffre en effet de ces petits >>> problèmes. Tout ce qui vise à l'améliorer est forcément à mettre dans >>> une roadmap.
> Je me suis aussi lancé dans le ticket 1072. J'en ai énormément besoin, donc > je pense que j'arriverai à fournir une branche à fusionner "assez > rapidement".
j'ai commenté là dessus aujourd'hui. N'hésite pas à revenir vers moi pour qu'on en discute. Comme je l'ai écrit, je propose d'ajouter en fait juste un système de plugin pour générer le HTML, en plus des builders (grosso merdo).
(et pousse tes commits sur ton depot pour que je puisse suivre de plus prêt :-)
>>> > D'autres chantiers ?
> Supprimer la gestion d'autres charset qu'UTF-8. Pas forcément dur à faire, > et ça simplifie l'utilisation du framework.
Oui mais ça, ça casse les modules (il n'y a plus besoin de 'UTF-8' dans les noms des fichiers etc) et les applis... ça necessite une grosse migration pour le développeur car si il n'était pas en UTF-8, il va lui falloir convertir toutes ses données. (on peut renommer/convertir les fichiers properties lors d'un update, mais ce n'est pas suffisant je pense).
Bref je pense qu'il faut réserver ça pour une 2.0 et c'est dans la roadmap de la 2.0 (qui contient plein de belles choses :).
>>> > A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on bascule >>> > directement sur Jelix2. Mais j'ai peur qu'au final, on ne sorte pas de >>> > versions avant un an voir plus... (sauf si on s'y met tous, peut être >>> > que... ;-) )
>>> Il faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop >>> longue sans les moyens qui vont avec. >>> La seule problématique dans ce cas est la gestion des versions de >>> maintenance. Il faudrait voir la politique qu'on voudrait adopter (mais >>> liée finalement aux moyens disponibles).
> Je pense aussi qu'il faut y aller en petite version... Surtout que ça donne > une vitalité au projet. > Peut être gérer en time release de 3 mois ? Ca donne une vitalité au projet, > ca force à avancer dans le projet et ca permet de gérer les fenêtres de > merge.
3 mois, vu l'activité, c'est court, il n'y aura pas grand chose en 3 mois. je dirais plutôt 5-6 mois. Mais sur le principe je suis d'accord. C'est ce que j'essaie de faire mais pas facile au final. Ou alors améliorer le processus de contribution ?
>> > Divers : >> > Sinon à l'allure où on va dans nos idées je nous vois mal les produire >> > sur >> > la branche v1.x surtout comme le souligne Loïc quant aux ressources en >> > face >> > "des" chantiers.
>> tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, n'est-ce >> pas ?
> Non je disais bien sur la branche 1.x > Je nous vois pas produire tout cela sur la branche 1.x, vue les forces en > présences de la tâche qui n'est pas annodine ou bien alors en découpant très > finement > ce qui ferait l'objet de chq petite version. genre une version une feature > ?
Au contraire, je trouve qu'il faut faire ça sur des versions 1.x. D'une part parce qu'à priori, ça ne cassera pas grand chose lors des migrations, et de plus, on pourra faire des releases plus rapide.
Mettre ça dans une 2.0, cela veut dire version majeure, et donc qui dit version majeure, dit en profiter pour casser tout les trucs obsolètes, voir réarchitecturer le coeur, corriger les erreurs d'architecture du passé, et utiliser un max de feature de PHP 5.3 (ou 5.4 maintenant). C'est à dire qu'il y a un max de chose à faire (voir la roadmap 2.0). Après ça seulement on pourra intègrer les autres chantiers. Conclusion: on ne sortira pas de 2.0 avant un an, et il faudra attendre un an pour avoir les améliorations dans jforms par exemple ? ça ne va pas être possible là. Il faut releaser le plus souvent possible.
Je suis plus que favorable à des release un peu moins fournies mais plus rapides, ça amène une dynamique au projet.
Concernant les changements de stockage pour jForms/jLocale, laurent tu parles de NoSQL via jKvDB, j'aime l'idée mais je pense à ceux qui utilise du mutualisé : ils seront obligés d'utiliser les drivers file/MySQL de JKvDB (car pas de NoSQL sur du mutualisé). N'est-ce pas une perte de performances dans ces cas la ?
Le 11 janvier 2012 16:27, Laurent Jouanneau <ljouann...@gmail.com> a écrit :
> Le 11 janvier 2012 16:19, FoxMaSk <foxm...@gmail.com> a écrit :
> >> > Divers : > >> > Sinon à l'allure où on va dans nos idées je nous vois mal les produire > >> > sur > >> > la branche v1.x surtout comme le souligne Loïc quant aux ressources en > >> > face > >> > "des" chantiers.
> >> tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, > n'est-ce > >> pas ?
> > Non je disais bien sur la branche 1.x > > Je nous vois pas produire tout cela sur la branche 1.x, vue les forces en > > présences de la tâche qui n'est pas annodine ou bien alors en découpant > très > > finement > > ce qui ferait l'objet de chq petite version. genre une version une > feature > > ?
> Au contraire, je trouve qu'il faut faire ça sur des versions 1.x. > D'une part parce qu'à priori, ça ne cassera pas grand chose lors des > migrations, et de plus, on pourra faire des releases plus rapide.
> Mettre ça dans une 2.0, cela veut dire version majeure, et donc qui > dit version majeure, dit en profiter pour casser tout les trucs > obsolètes, voir réarchitecturer le coeur, corriger les erreurs > d'architecture du passé, et utiliser un max de feature de PHP 5.3 (ou > 5.4 maintenant). C'est à dire qu'il y a un max de chose à faire (voir > la roadmap 2.0). Après ça seulement on pourra intègrer les autres > chantiers. Conclusion: on ne sortira pas de 2.0 avant un an, et il > faudra attendre un an pour avoir les améliorations dans jforms par > exemple ? ça ne va pas être possible là. Il faut releaser le plus > souvent possible.
Le 17 janvier 2012 11:28, Florian Lonqueu-Brochard <f.lonqueu.broch...@gmail.com> a écrit :
> Concernant les changements de stockage pour jForms/jLocale, laurent tu > parles de NoSQL via jKvDB, j'aime l'idée mais je pense à ceux qui utilise du > mutualisé : ils seront obligés d'utiliser les drivers file/MySQL de JKvDB > (car pas de NoSQL sur du mutualisé). N'est-ce pas une perte de performances > dans ces cas la ?
à vérifier, mais je pense que les fonctions dba sont activés par défaut
Il resterai plus qu'à faire un driver jKvDb pour dba (qui lui même est une couche abstraite de bases nosql fichiers :) )
Si vous avez un hebergement mutu (ou pas d'ailleurs, pour voir si c'est aussi par défaut dans les distro), pouvez vous vérifier ça et me renvoyer le résultat, en indiquant l'hebergeur ou la distro ?
<?php header('Content-type', 'text/plain'); if (function_exists('dba_handlers') { echo "Available DBA handlers:\n"; foreach (dba_handlers() as $handler_name) { echo $handler_name.','; }
> Le 11 janvier 2012 16:27, Laurent Jouanneau <ljouann...@gmail.com> a écrit :
>> Le 11 janvier 2012 16:19, FoxMaSk <foxm...@gmail.com> a écrit :
>> >> > Divers : >> >> > Sinon à l'allure où on va dans nos idées je nous vois mal les >> >> > produire >> >> > sur >> >> > la branche v1.x surtout comme le souligne Loïc quant aux ressources >> >> > en >> >> > face >> >> > "des" chantiers.
>> >> tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, >> >> n'est-ce >> >> pas ?
>> > Non je disais bien sur la branche 1.x >> > Je nous vois pas produire tout cela sur la branche 1.x, vue les forces >> > en >> > présences de la tâche qui n'est pas annodine ou bien alors en découpant >> > très >> > finement >> > ce qui ferait l'objet de chq petite version. genre une version une >> > feature >> > ?
>> Au contraire, je trouve qu'il faut faire ça sur des versions 1.x. >> D'une part parce qu'à priori, ça ne cassera pas grand chose lors des >> migrations, et de plus, on pourra faire des releases plus rapide.
>> Mettre ça dans une 2.0, cela veut dire version majeure, et donc qui >> dit version majeure, dit en profiter pour casser tout les trucs >> obsolètes, voir réarchitecturer le coeur, corriger les erreurs >> d'architecture du passé, et utiliser un max de feature de PHP 5.3 (ou >> 5.4 maintenant). C'est à dire qu'il y a un max de chose à faire (voir >> la roadmap 2.0). Après ça seulement on pourra intègrer les autres >> chantiers. Conclusion: on ne sortira pas de 2.0 avant un an, et il >> faudra attendre un an pour avoir les améliorations dans jforms par >> exemple ? ça ne va pas être possible là. Il faut releaser le plus >> souvent possible.
> Le 17 janvier 2012 11:28, Florian Lonqueu-Brochard > <f.lonqueu.broch...@gmail.com> a écrit : > > Concernant les changements de stockage pour jForms/jLocale, laurent tu > > parles de NoSQL via jKvDB, j'aime l'idée mais je pense à ceux qui > utilise du > > mutualisé : ils seront obligés d'utiliser les drivers file/MySQL de JKvDB > > (car pas de NoSQL sur du mutualisé). N'est-ce pas une perte de > performances > > dans ces cas la ?
> à vérifier, mais je pense que les fonctions dba sont activés par défaut
> Il resterai plus qu'à faire un driver jKvDb pour dba (qui lui même est > une couche abstraite de bases nosql fichiers :) )
> Si vous avez un hebergement mutu (ou pas d'ailleurs, pour voir si > c'est aussi par défaut dans les distro), pouvez vous vérifier ça et me > renvoyer le résultat, en indiquant l'hebergeur ou la distro ?
> > Le 11 janvier 2012 16:27, Laurent Jouanneau <ljouann...@gmail.com> a > écrit :
> >> Le 11 janvier 2012 16:19, FoxMaSk <foxm...@gmail.com> a écrit :
> >> >> > Divers : > >> >> > Sinon à l'allure où on va dans nos idées je nous vois mal les > >> >> > produire > >> >> > sur > >> >> > la branche v1.x surtout comme le souligne Loïc quant aux ressources > >> >> > en > >> >> > face > >> >> > "des" chantiers.
> >> >> tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, > >> >> n'est-ce > >> >> pas ?
> >> > Non je disais bien sur la branche 1.x > >> > Je nous vois pas produire tout cela sur la branche 1.x, vue les forces > >> > en > >> > présences de la tâche qui n'est pas annodine ou bien alors en > découpant > >> > très > >> > finement > >> > ce qui ferait l'objet de chq petite version. genre une version une > >> > feature > >> > ?
> >> Au contraire, je trouve qu'il faut faire ça sur des versions 1.x. > >> D'une part parce qu'à priori, ça ne cassera pas grand chose lors des > >> migrations, et de plus, on pourra faire des releases plus rapide.
> >> Mettre ça dans une 2.0, cela veut dire version majeure, et donc qui > >> dit version majeure, dit en profiter pour casser tout les trucs > >> obsolètes, voir réarchitecturer le coeur, corriger les erreurs > >> d'architecture du passé, et utiliser un max de feature de PHP 5.3 (ou > >> 5.4 maintenant). C'est à dire qu'il y a un max de chose à faire (voir > >> la roadmap 2.0). Après ça seulement on pourra intègrer les autres > >> chantiers. Conclusion: on ne sortira pas de 2.0 avant un an, et il > >> faudra attendre un an pour avoir les améliorations dans jforms par > >> exemple ? ça ne va pas être possible là. Il faut releaser le plus > >> souvent possible.
pour le noSql, il y a mongolab et mongohq qui propose des comptes gratuit ;) pour l' hebergement, il y a cloudfoundries, dotcloud et heroku ou l'utilisation de base noSQL est possible.
Chez OVH : (php 5.2.17) gdbm cdb cdb_make inifile flatfile (et db3 sur les offres != perso) Chez free : (php 5.1.3) gdbm cdb cdb_make db4 inifile flatfile Chez online : (php 5.2.9) gdbm cdb cdb_make db4 inifile flatfile Chez sivit, juste db4 à priori.
Tout ça est à vérifier quand même. J'ai eu ces infos via les phpinfo() qu'ils montrent. Mais ça arrive que ce soit sur des serveurs autres que ceux des hebergements mutualisés et donc ne sont pas forcément à jour...
M'enfin il y a de bonnes chances que ce soit activé chez la majorité des hebergeurs. Toutes confirmation et infos complémentaires bienvenues.
Le 18 janvier 2012 01:20, Vincentv <lsun...@gmail.com> a écrit :
> pour le noSql, il y a mongolab et mongohq qui propose des comptes gratuit ;) > pour l' hebergement, il y a cloudfoundries, dotcloud et heroku ou > l'utilisation de base noSQL est possible.
> Chez OVH : (php 5.2.17) gdbm cdb cdb_make inifile flatfile (et db3 sur > les offres != perso) > Chez free : (php 5.1.3) gdbm cdb cdb_make db4 inifile flatfile > Chez online : (php 5.2.9) gdbm cdb cdb_make db4 inifile flatfile > Chez sivit, juste db4 à priori.
> Tout ça est à vérifier quand même. J'ai eu ces infos via les phpinfo() > qu'ils montrent. Mais ça arrive que ce soit sur des serveurs autres > que ceux des hebergements mutualisés et donc ne sont pas forcément à > jour...
> M'enfin il y a de bonnes chances que ce soit activé chez la majorité > des hebergeurs. > Toutes confirmation et infos complémentaires bienvenues.
> Le 18 janvier 2012 01:20, Vincentv <lsun...@gmail.com> a écrit : > > pour le noSql, il y a mongolab et mongohq qui propose des comptes > gratuit ;) > > pour l' hebergement, il y a cloudfoundries, dotcloud et heroku ou > > l'utilisation de base noSQL est possible.
