Gros chantiers à venir. En vrac et à commenter.
Laurent Jouanneau
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).
Pour les gros chantiers qui casseraient tout, voir la roadmap pour
Jelix 2.0 : http://developer.jelix.org/query?milestone=Jelix+2.0
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
Voir http://developer.jelix.org/wiki/rfc/autoload pour les détails
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)
Voir http://developer.jelix.org/wiki/rfc/new-url-routing pour les détails
4) jAuth : amélioration pour la prise en charge des authentifications
déportées (oAuth, OpenId etc).
5) améliorations pour faciliter la prise en charge de différents
environnement : production, dev, test etc..
6) Amélioration des performances de jLocale
voir http://developer.jelix.org/wiki/rfc/jlocale-storage
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).
voir : http://developer.jelix.org/wiki/rfc/jforms-storage
8) jForms: plugins pour générer des contrôles personnalisés.
voir : http://developer.jelix.org/ticket/1072
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... ;-) )
Laurent
Loic Mathaud
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).
> Pour les gros chantiers qui casseraient tout, voir la roadmap pour
> Jelix 2.0 : http://developer.jelix.org/query?milestone=Jelix+2.0
>
> 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
>
> Voir http://developer.jelix.org/wiki/rfc/autoload pour les d�tails
+1
> 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)
>
> Voir http://developer.jelix.org/wiki/rfc/new-url-routing pour les d�tails
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..
yes :)
> 6) Am�lioration des performances de jLocale
> voir http://developer.jelix.org/wiki/rfc/jlocale-storage
am�lioration + performance, encore oui.
> 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).
>
> voir : http://developer.jelix.org/wiki/rfc/jforms-storage
>
> 8) jForms: plugins pour g�n�rer des contr�les personnalis�s.
>
> voir : http://developer.jelix.org/ticket/1072
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.
Loic
FoxMaSk
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.
Hello à tous,
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).
> Pour les gros chantiers qui casseraient tout, voir la roadmap pour
> Jelix 2.0 : http://developer.jelix.org/query?milestone=Jelix+2.0
>
> 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 maisJe passe certainement à côté de cet exemple dans le fait qu'il illustre
> seraient marqué déprécié. Ce matin dans le train, j'ai commencé
> jApp::config().
"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 faitC'est en effet une amélioration non négligeable qui ouvre la porte à des
> en sorte que ça reste compatible avec du vieux code)
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+1
>
> Voir http://developer.jelix.org/wiki/rfc/autoload pour les détails
> 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 niveauSi on arrive à faire une transition en douceur qui ne casse pas trop
> 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)
>
> Voir http://developer.jelix.org/wiki/rfc/new-url-routing pour les détails
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.
Améliorer jAuth ne peut qu'être une bonne idée :)
> 4) jAuth : amélioration pour la prise en charge des authentifications
> déportées (oAuth, OpenId etc).
> 5) améliorations pour faciliter la prise en charge de différents
> environnement : production, dev, test etc..
yes :)
amélioration + performance, encore oui.
> 6) Amélioration des performances de jLocale
> voir http://developer.jelix.org/wiki/rfc/jlocale-storage
> 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).
>
> voir : http://developer.jelix.org/wiki/rfc/jforms-storage
>
> 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
>
> voir : http://developer.jelix.org/ticket/1072
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'unBonne idée :)
> DAO avec ça
pas forcément urgent je pense, mais à caser dans 1.x est une bonne idée.
> 10) jDb : driver mysqli / utilisation d'une API récente de mysql.
> 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.
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 êtreIl faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop
> que... ;-) )
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.
Loic
http://www.foxmask.info Le Grin de Sable
http://www.havefnubb.org HaveFnuBB le forum, PHP5 powered by Jelix, libre et gratuit
http://www.huanui.org Huanui, projet de microblogging avec Jelix.
Laurent Jouanneau
>> Donc pour une 1.4 et suivante, voici ce que je propose. Tout
>
> Je suppose que la numérotation n'est pas liée à un ordre de priorités ?
Non du tout.
>
>> 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)
>>
>> Voir http://developer.jelix.org/wiki/rfc/new-url-routing pour les détails
>
> 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" ;)
Yes :-)
Merci de tes retours
Laurent
obs
> 3) suppression du système de moteurs d'URLSi on arrive à faire une transition en douceur qui ne casse pas trop
> 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)
>
> Voir http://developer.jelix.org/wiki/rfc/new-url-routing pour les détails
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.
Améliorer jAuth ne peut qu'être une bonne idée :)
> 4) jAuth : amélioration pour la prise en charge des authentifications
> déportées (oAuth, OpenId etc).
> 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
>
> voir : http://developer.jelix.org/ticket/1072
problèmes. Tout ce qui vise à l'améliorer est forcément à mettre dans
une roadmap.
> D'autres chantiers ?
> A voir aussi si on fait vraiment une 1.4/1.5 etc, ou si on basculeIl faut 1.4, 1.5, 1.6, ... on a déjà fait les frais d'une roadmap trop
> 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... ;-) )
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).
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.
Laurent Jouanneau
> 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 ?
Laurent
FoxMaSk
> Divers :tu voulais dire, "en dehors de", et pas "sur", la branche v1.x, n'est-ce pas ?
> 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.
Laurent Jouanneau
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 ?
Laurent
Laurent Jouanneau
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.
(au final, 3 mois c'est pas mal ;-) )
Florian Lonqueu-Brochard
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 ?
Laurent Jouanneau
<f.lonqueu...@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
http://www.php.net/manual/en/book.dba.php
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.',';
}
}
else
echo "no dba\n";
Antoine MOREL
Vincentv
Laurent Jouanneau
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.