Bonjour Laurent,

Merci à Laurent et aux contributeurs qui font de jelix un incontournable, robuste, efficace et simple framework php à prendre en main. Notamment de par sa conception et sa documentation et tout ce qui fait que Jelix est Jelix.

L'objet de mon post est de proposer l'amélioration de la classe de gestion du CRUD (lib/jelix/controllers/jControllerDaoCrud.class.php) :

Afin de permettre la propagation de paramètres d'url aux différentes actions. Notamment par exemple pour gérer l'ordre asc ou desc d'une colonne de la liste affichée dans le CRUD à l'ensemble des actions create, update etc... et de se retrouver au même endroit dans la liste (avec le bon classement sur la bonne colonne et la bonne page et pas revenir sur la bonne page avec perte de l'odre de tri et de la colonne impliquée dans le tri), d'où que l'on vienne depuis n'importe qu'elle action du CRUD (apres un create, un view, un update).

Il conviendrait de :

• changer la signature de :

protected function _preCreate($form)

en protected function _preCreate($form, $resp)

• changer la signature de :

protected function _preUpdate($form)

en protected function _preUpdate($form, $resp)

• dans la fonction precreate() changer l'ordre de :

...
$this->_preCreate($form);

$rep = $this->getResponse('redirect');

...

en (avec en plus l'ajout du parametre $rep à l'appel de _preCreate())

...
$rep = $this->getResponse('redirect');

$this->_preCreate($form, $rep);

...

• Modifier l'appel dans preupdate() de

$this->_preUpdate($form);

en $this->_preUpdate($form, $rep);

Pour les autres fonctions _index ou autre, on peut agir directement sur le $tpl (template) passé en paramètre de la fonction en recuperant dans un premier temps les paramètres d'url puis en assignant ces valeurs de paramètre d'url aux variables adhoc du template.

En espérant que ces propositions puisse être intégrées.

Cordialement e-media

Bonjour,

merci pour jelix :)

Sinon pour le contrôleur, faut voir. Le problème des évolutions proposées est que ça casse l'existant.. Si je le fais, ça sera pour la 1.4, pas avant.

Ok vu Je crée un ticket ou pas alors pour la 1.4 ?

Des pistes succintes (ou un peu plus de précisions, c'est pour ma culture sur le coeur de Jelix) pour les implications qui m'échappent à mon niveau de connaissance de Jelix.

Merci pour ton retour.

Un contournement est la création dans le projet d'une classe qui surcharge la classe jControllerDaoCrud de Jelix avec les modifications du post.

Dans myProject/modules/myModule/classes/myjControllerDaoCrud.class.php on définit la surcharge de jControllerDaoCrud :

class myjControllerDaoCrud extends jControllerDaoCrud {
// en reprenant le code et en intégrant les modifications dont j'ai besoin.
...
}

puis pour mes controleurs crud qui nécessitent ces modifications, d'utiliser cette classe comme ceci :

<?php
global $gJCoord;
@include $gJCoord->getModulePath('myModule').'classes/myjControllerDaoCrud.class.php';

class defaultCtrl extends myjControllerDaoCrud {
...
}

Ainsi je ne modifie par le core Jelix directement mais seulement myProject. Il faudra bien sûr suivre les évolutions de jControllerDaoCrud.class.php et intégrer les Majs dans myjControllerDaoCrud.class.php

J'ai eu la même problématique de pouvoir propager des paramètres de la page d'index aux autres pages d'actions dont, l'ajout, la modif, la suppression et le changement de page (pagination).

Je me suis demandé comment faire :

• modifier la classe "jControllerDaoCrud", => mais c'est pas génial lors de la sortie de nouvelles versions
• créer un genre de plugin à part pour pouvoir l'intégrer facilement dans n'importe quelle application?
• Créer ma classe, "myControllerDaoCrud" à mettre dans le dossier classe de chacun de mes modules (au niveau maintenance ça veut dire répliquer cette classe partout...)

Je ne maîtrise pas assez jelix pour savoir ce qui serait le mieux, tout ce que je sais c'est qu'un nouvelle class crud plus "sexy" serait pas de refus, j'ai donc choisi la 3ème option pour le moment pour que ça colle à mes besoins. Mais en terme de maintenance je suis pas sûr que ce soit un gain de temps. Pour info j'ai dû aussi modifier les templates générés par CRUD...

Vous pensez qu'il serait possible d'avoir l'ancien CRUD et un nouveau CRUD (gérant de nouvelles fonctionnalités) cote à cote pour la version 1.4? Histoire de pas toucher à l'ancien CRUD pour ceux qui le trouvent adaptés à leur besoin.

Bref si vous avez des avis et idées sur la question, hésitez pas!

au fait pour ça :

<?php
global $gJCoord;
@include $gJCoord->getModulePath('myModule').'classes/myjControllerDaoCrud.class.php';

pourquoi n'utilises-tu pas plutôt cette ligne?

<?php
jClasses::inc('myjControllerDaoCrud');

Créer ma classe, "myControllerDaoCrud" à mettre dans le dossier classe de chacun de mes modules

non, tu n'as pas besoin. Comme le montre l'exemple de e-media, tu mets ta classe dans un module, et dans les modules que tu as besoin, tu l'inclus direct.

Tu pourrais te faire un module "fourre-tout", dans lequel tu y mets ce qui est commun à d'autres.

pourquoi n'utilises-tu pas plutôt cette ligne?

Ce serait effectivement plus conci. Il manque cependant le nom du module dans le selecteur ;-)

jClasses::inc('mymodule~myjControllerDaoCrud');

Tu pourrais te faire un module "fourre-tout", dans lequel tu y mets ce qui est commun à d'autres.

Hum ça peut effectivement être une idée, merci!

Il manque cependant le nom du module dans le selecteur

Et bien en fait c'était fait exprès :) Dans la logique de réutilisation du code "tel quel" sans faire trop de modif, j'ajoute rarement le nom du module pour que ce soit le module "en cours" qui soit pris par défaut. Si jamais je dois utiliser le code pour un autre module, la ligne n'est pas à changer! Et pour cet include, ça marche :)

Et bien en fait c'était fait exprès

Oui mais dans le cas d'utilisation des classes dans classes/, il faut faire gaffe. jClasses ne change pas le contexte d'execution "module", car il ne sait pas ce que tu fais par la suite.

Exemple :

A.class.php dans module MA

jClasses::inc('B');
class A extends B {...}

B.class.php se trouve elle aussi dans MA.

C.class.php dans module MB

jClasses::inc('A');
class C extends A {...}

• > erreur, car dans A.class.php, tu n'a pas indiqué de module dans le selecteur. Or le module courant c'est MB, pas MA, au moment de l'execution du jClasses::inc('B');.

Dans un .class.php, le module courant n'est pas forcément celui de la classe en question. Donc toujours renseigner les modules dans les selecteurs dans les "classes/".