bonjour, débutant sur Jelix, je suis en train d'effectuer un module dans lequel j'ai inséré un formulaire de saisie (jusque ici pas de soucis lol) Je voudrais insérer une fonction update, pour remplacer un champ lorqu'on le modifie. quelle est la syntaxe de cette formule ?

merci ;-)

Pour être plus précis, le but du jeu est d'implémenter un controleur fournissant les méthodes de base:

• listAll
• create
• show
• delete
• edit

Le problème se situe dans les méthodes edit et save, que voici:

 function edit(){
                $job_id=$this->param('job_id'); //on récupère la pkey de l'objet à éditer
                $form = jForms::create('jobOffer'); //on crée le jForm
                $factory=jDAO::get('jobs'); //on récupère le record associé à la pkey
                $form->initFromDao('jobs'); //
                $rep= $this->getResponse("html");
                $rep->title='Edit Job Offer';
                $rep->body->assign('job', $factory->get($job_id));
                $rep->body->assign('params',array('job_id'=>$job_id));
                $rep->bodyTpl='jobOfferForm';
                return $rep;
 }

L'action appellée par la validation du formulaire est save (qui est également appellée par l'action create).

 function save(){
      // récuper le formulaire
      $form = jForms::fill('jobOffer');

Le problème se situe ici :

      $daoRec=$form->saveToDao('jobs'); //sauvegarder le formulaire dans la db
      $rep= $this->getResponse("redirect");
      $rep->action="show";
      $rep->params=array('job_id'=>$daoRec->job_id);
      return $rep;
 }

En regardant le code source de jForm->saveToDao(), on voit qu'il peut faire un UPDATE au lieu d'un INSERT, mais je ne sais pas comment le lui signifier. Comme la pkey doit être unique, il me retourne une erreur sur l'insert.

De façon plus générale, une fois ce problème résolu, je pense qu'il serait intéressant de pouvoir fournir un implémentation par défaut des actions les plus courantes, au hasard celles citées en début de message. Est-ce prévu ? Un patch de la commande jelix createController vous intéresserait-il ? A défaut, les fournir en tant qu'exemple dans la doc ferait gagner pas mal de temps à ceux qui débutent ;)

Merci !

Lors du jForms::create, tu as un deuxième paramètre, un identifiant unique pour ton formulaire. En général, on donne l'identifiant de l'enregistrement ($job_id dans ton cas apparement).

Lors du save, si tu as donné cet id lors du create, il fait un update, sinon il fait un insert.

À noter que jForms n'est pas tout à fait terminé (entre autre j'aimerai ajouter la génération de formulaire HTML ou autre à partir d'un jform). Ne t'etonnes donc pas si il y a des bugs, et tes retours nous seront précieux. Donc n'hésite pas à nous signaler des bugs, des choses embétantes dans jForms au niveau utilisation etc.. ;-)

je pense qu'il serait intéressant de pouvoir fournir un implémentation par défaut des actions les plus courantes, au hasard celles citées en début de message.

C'est ce qui est tout à fait prévue :-) voir la tâche correspondante.

Dans l'idée, il y aura donc un contrôleur (ce qu'on appelle un controleur crud) comportant ce genre d'action. Il suffira de créer un contrôleur héritant du controleur crud, et de spécifier certaines propriétés, comme les templates à utiliser, le formulaire à utiliser, le dao à utiliser etc.. Et tout se fera tout seul :-)

$rep->action="show";

Attention, ton nom d'action ne semble pas complet (manque le nom du controleur..)

Laurent

Comme son nom l'indique, $internalIdName est un nom : celui du paramètre dans $_GET ou $_POST contenant l'id interne à jForm du formulaire (l'id interne étant calculé à partir de l'id que tu as donné). En effet, pour que jForm récupère les bonnes données en session, il faut dans le formulaire html, stocker cette id interne dans un input hidden (par exemple).

(en fait, il peut y avoir plusieurs formulaires du même type en même temps en session, mais contenant chacun un enregistrement différent. Ceci pour ne pas avoir de problème si l'utilisateur ouvre plusieurs fenêtres ou onglets sur la même page mais avec des données différentes).

Bref. à jForms::get, tu es censé donné ce nom de paramètre, contenant l'id interne. Si sa récupération échoue (donc internalId= null), on en calcule un. Sinon, on l'a donc il n'y a rien à faire (et ta correction causerait un bug).

Pour résumé :

• il s'agit d'un formulaire pour un modifier un enregistrement, un dao : on fourni l'id de l'enregistrement à create, et on doit prévoir un champs caché contenant l'id interne du formulaire dont on fourni le nom à get/fill/destroy.
• il s'agit d'un formulaire à saisie "unique", avec lequel en fait on ne fait que créer des données, pas les modifier (par exemple, un formulaire de contact pour envoyer un mail), dans ce cas, on a pas besoin d'id. Donc on appelle create/get/fill/destroy avec uniquement le nom du formulaire.

Désolé pour l'absence totale de doc sur jForm :-)

pourquoi faire un md5 sur un identifiant que l'on sait unique ?

parce qu'une clé de table peut être basée sur plusieurs champs ;-) Donc en fait il est prévu que tu puisses donner par exemple array('foo','bar') comme id. Par contre, je crois qu'il y a un bug au niveau du calcul du md5 : il me semble que je dois faire un serialize, md5 n'acceptant que des chaines (ou autre type qui peut être casté en string)... Je ne sais plus...

regarde dans testapp, il y a des exemples d'utilisation de jform

Je ne dois pas avoir les yeux en face des trous, mais je ne comprends pas. Prenon le cas d'une édition, en deux action, edit et delete. Dans mon action edit, je crée une formulaire avec JForm::create, en lui donnant en paramètre l'id de l'élément à éditer:

 function edit(){
        $id=$this->param('id');
        $form = jForms::create('nouvellenews',$id);
 [blah ...]
 }

Mon template de formulaire contient bien un champ hidden qui va bien. La fonction create, si j'en crois le source, va calculer le md5 de cet id et utiliser cette valeur comme index:

 $_SESSION['JFORMS'][$formSel][$internalId] //$internalId vaut md5($id)

Lorsque je valide mon formulaire, j'arrive dans l'action save et apelle le formulaire stocké en session avec:

 $form = jForms::fill('nouvellenews','id');

JForms::fill commence par faire un JForms::get('nouvellenews','id') Puis récupère l'id dans le champ hidden du formulaire avec:

 $internalId = $gJCoord->request->getParam($internalIdName);

Il va ensuite chercher en session sans faire de md5 sur l'id avec:

      if(!isset($_SESSION['JFORMS'][$formSel][$internalId])){
          return null;
      }

forcément, il n'y a rien, et je reçois systématiquement null.

Je persiste à penser que ma corection est pertinente, le problème étant très simple:

• On applique systèmatiquement un md5 à l'index quand on stocke dans le tableau
• On n'applique pas toujours un md5 au momment d'aller chercher dans le tableau

Ou alors je suis mal reveillé ;)

il va ensuite chercher en session sans faire de md5 sur l'id avec

c'est normal, puisque dans ton champs hidden, tu dois y stocker le md5($id) (ou plus exactement, $tonForm->id() ). Donc quand jForms le récupère, pas de md5 à faire..

En fait, le create, tu n'es censé l'appelé qu'une fois, lors de la préparation du formulaire avant l'édition. Tu devrais donc avoir une action qui fait un create puis redirige vers l'action d'edition. Celle -ci fait un get et affiche le formulaire.

Cela permet par exemple de revenir à l'action edit (aprés action prévisualisation/confirmation ou aprés erreur lors du save), sans que le create ne soit fait à chaque fois.

Donc je ne pense toujours pas qu'il y ait un bug au niveau que tu as dit :-)

Mais peut être qu'effectivement, l'API est un peu confuse et qu'il faudrait l'améliorer..

Ah ok, on est d'accord. Et ça marche en plus. Donc effectivement, pas de bug, le tout c'était de savoir qu'il fallait stocker $form->id().

Merci de ton aide !

De rien :-)

(je cherche des volontaires pour compléter la doc ;-) )

ok, galves et moi nous portons volontaires. Nous l'aurions bien fait avant, mais le wiki est fermé en écriture...