Bonjour et félicitation pour votre travail!

J'aurai une petite suggestion pour gagner beaucoup de temps. Je cherche à minimiser le volume de code en utilisant les jForms et finalement je suis obligé de redéfinir beaucoup de code.

Explications : On va dire que j'ai une table contenant des adhérents. A chaque fois que j'ajoute un enregistrement, je souhaiterais savoir qui l'a fait et à quand.

Pour le "quand" aucun problème avec insertpattern="NOW()" directement dans le dao de la table. Pour le "qui" j'aurais bien aimé récupéré l'id de la personne connectée via jAuth

J'utilise jAuth avec le dao user.dao.xml (ci-dessous) Je comptais donc pouvoir ajouter systématiquement l'id de la personne connecté en le récupérant avec jAuth::getUserSession()->usr_id. Au lieu de ça je crois être obligé de surcharger function savecreate() et de réaffecter tous les champs.

En gros cela pourait donner quelque chose comme ça et ce serait je pense très interessant.

DAO user.dao.xml pour jAuth

 <property name="usr_id"    fieldname="usr_id"       datatype="autoincrement"    required="true" />
 <property name="login"    fieldname="usr_login"       datatype="string"    required="true" />
 <property name="password"    fieldname="usr_pass"       datatype="string"    required="true" />
 <property name="usr_email"    fieldname="usr_email"       datatype="string"    required="false" />
        

DAO adherent.dao.xml

 <property name="cad_id"    fieldname="cad_id"       datatype="autoincrement"    required="true" />
 <property name="cad_nom"    fieldname="cad_nom"       datatype="string"    required="true" />
 <property name="cad_prenom"    fieldname="cad_prenom"       datatype="string"    required="true" />
 <property name="cad_creation_date"    fieldname="cad_creation_date"       datatype="datetime"    required="true" insertpattern="NOW()" updatepattern="NOW()" />
 <property name="usr_create"    fieldname="usr_create"       datatype="integer"    required="true" insertpattern="jAuth::getUserSession()->usr_id" updatepattern="jAuth::getUserSession()->usr_id" />

Suis je passé à côté de quelque chose pour ce genre de fonctionnalité ? Y a t il une autre démarche pour ajouter des valeurs à un DAO côté serveur tout juste avant insertion/modification ?

Bon déjà, tu n'es pas obligé d'utiliser le user.dao.xml. Ou tu peux le redéfinir. Par exemple faire plutôt ça pour adherent.dao.xml

 <property name="usr_id"    fieldname="cad_id"       datatype="autoincrement"    required="true" />
 <property name="login"     fieldname="usr_login"       datatype="string"    required="true" />
 <property name="password"  fieldname="usr_pass"       datatype="string"    required="true" />
 <property name="usr_email" fieldname="usr_email"       datatype="string"    required="false" />
 <property name="cad_nom"    fieldname="cad_nom"       datatype="string"    required="true" />
 <property name="cad_prenom"    fieldname="cad_prenom"       datatype="string"    required="true" />
 <property name="cad_creation_date"    fieldname="cad_creation_date"       datatype="datetime"    required="true"  insertpattern="NOW()" updatepattern="NOW()" />
 <property name="usr_create"    fieldname="usr_create"       datatype="integer"    required="true" />

ainsi tu n'as qu'une table, et tu indique ce dao dans la conf du plugin jauth. Note que le name et le fieldname ne sont pas obligatoirement équivalent. Donc si le champs login ne s'appelle pas usr_login, c'est pas grave, tu peux l'avoir autrement. Cependant le nom de la propriété doit rester "login" pour que jAuth puisse y accéder.

Pour les patterns : ils ne doivent contenir que du SQL. Donc impossible de mettre jAuth::getUserSession()->usr_id. Il faut que tu assigne la valeur à la main. Et je ne modifierais pas le fonctionnement des attributs pattern, parce qu'il sera impossible de déterminer si on a à faire à du SQL ou du PHP.

De plus, ton exemple est bancale. Et si on veut créer un user qui ne soit pas "nous" ? Avec ta solution, on ne pourrais pas.

Pour le moment donc, pas d'autre choix que d'assigner les valeurs à la main.

Le problème c'est que ca "ne marche pas" avec un jControllerDaoCrud.

"Et je ne modifierais pas le fonctionnement des attributs pattern, parce qu'il sera impossible de déterminer si on a à faire à du SQL ou du PHP."

Est-ce qu'on ne pourrait pas ajouter des *patternphp qui seraient mutuellement exclusifs avec le *pattern correspondant ? Il suffirait de passer le code php dans un eval(). (Feature proposée dans le ticket 345)

Merci pour la réponse mais je reste sur ma faim. Je suis très enthousiaste à l'idée d'utiliser jControllerDaoCrud, mais ça coince sur des cas simple et du coup je pense être obligé de rajouter et surcharger du code, voir de de laisser tomber le crud.

J'avais simplifié l'exemple pour faire simple, mais en l'occurence si j'ai N tables + 1 table USER et que pour les N tables j'ai besoin de savoir à chaque fois qui a fait l'insertion/modification pour une question de traçabilité. Je pense réellement que c'est un cas que beaucoup de personne sont amenées à rencontrer. Bien sur on peut tout faire à la main, mais je trouvais ça dommage de rajouter beaucoup de code (surtout quand on a pas mal de colonnes) et casser l'interet de jControllerDaoCrud alors que tout est presque en place. Est ce que tu vois l'interet de la chose ?

C'est comme pour les dates, ce serait pas mal d'avoir meme pour un crud (peut être est ce prévu) quelque chose pour pour faire la conversion entre ce que saisi l'utilisateur et le format en BD. Exemple l'utilisateur saisi 20/11/2007 dans un input et automatiquement ce sera 2007-11-20 dans le dao, moyennant bien sur quelque chose dans le .form.xml du type :

 <input ref="cad_birthday" type="date" in="jDateTime::LANG_DFORMAT" out="jDateTime::BD_DFORMAT">
	<label>Date de naissance</label>
 </input>

Un crud reste un crud mais ce serait vraiment le pieds si on pouvait rajouter ce genre de petite fonctionnalité qui apporterait tant.

J'ai donc fini par faire un contrôleur spécifique. J'ai dans les grandes lignes :

 $form = jForms::fill($this->form);
 ...
 $form->setData('trace_user', $user_id); //Je ne fais pas confiance à l'utilisateur pour ce genre de donnée donc je le valorise côté serveur
 if($form->check() && $this->_checkDatas($form, false)){
 $id = $form->saveToDao($this->dao);
 ...}

Pour utiliser saveToDao tel quel au lieu de refaire des affectations champ par champ, j'ai rajouté dans le jForm :

 <input ref="trace_user" required="true" type="integer">
	<label>blabla</label>
 </input>

ce qui m'a contraint de revoir mes templates car je ne veux pas voir ce champ dans mes formulaires. Je suis passé de :

 {formcontrols}
  <tr><td> {ctrl_label} : </td><td> {ctrl_control}</td></tr>
 {/formcontrols}

à

 {formcontrols array('psl_tt_hdv', 'psl_tt_hb', ..., 'psl_total')}
  <tr><td> {ctrl_label} : </td><td> {ctrl_control}</td></tr>
 {/formcontrols}

Il y a bcp plus de champs en réalité, mais je m'accomode de cette solution. J'ai vu qu'il y aura en V1.2 une propriété "hidden" pour les jForm. Ce serait pas mal d'en avoir une en plus du genre "sideserver" pour qu'un input dans un jForm ne soit pas mis dans le formulaire mais qu'il puisse être valorisé facilement côté serveur.

 <input ref="trace_user" required="true" type="integer" sideserver="true">
	<label>blabla</label>
 </input>

Et du coup plus besoin de spécifier tous les champs dans les templates pour en exclure quelques un.

Où y a t il qqch de prévu déjà pour ce cas ?

Ca ne m'était pas venu à l'esprit que l'on pouvait faire

 $form->setData('trace_user', $user_id);

sans avoir dans le jForm correspondant

 <input ref="trace_user" required="true" type="integer">
	<label>Blabla</label>
 </input>

Je viens d'essayer et voilà le résultat

 [notice 1] Undefined index: trace_user  D:\XWAMP\wamp\www\jelix-b3.1\lib\jelix\forms\jFormsBase.class.php 396

 [notice 1] Trying to get property of non-object D:\XWAMP\wamp\www\jelix-b3.1\lib\jelix\forms\jFormsBase.class.php 396

Du coup quand on fait $form->setData('trace_user', $user_id) il faut bien qu'il existe dans l'objet $form la propriété trace_user ?

@laurent Par rapport à ce qu'écrit : Obewan le 22/11/2007 à 19h22

Effectivement il peut être intéressant de ne pas afficher certains champs définis dans le formulaire (XML) et si on a une liste importante de champs il serait pratique de pouvoir passer cette liste (par défaut vide) de la façon suivante (cf ci-dessous). C'est particulièrement intéressant si on a beaucoup de champs à afficher et peu à masquer.

Ce principe trouve tout son sens si on veut utiliser la même définition de formulaire (fichier XML) et avoir un affichage différent pour le formulaire de saisie (action edit du crudtuto3 par exemple) et le formulaire d'affichage seulement (view du crudtuto3 par exemple).

supposons que l'on ai les champs 'NOM','PRENOM','ADRESSE','CODE_POSTAL','VILLE','DATE_NAISSANCE' on veut tous les saisirs et tous les afficher sauf date de naissance.

Aujourd'hui pour tous les saisir on peut faire dans un template :

 ...
 {formcontrols array()}
	    <p>{ctrl_label}: {ctrl_control}</p>
 {/formcontrols}
 ...

pour l'affichage on peut faire

 ...
 {formcontrols array('NOM','PRENOM','ADRESSE','CODE_POSTAL','VILLE')}
	    <p>{ctrl_label}: {ctrl_control}</p>
 {/formcontrols}
 ...

Une évolution qui pourrait être faite : c'est de passer en paramètre un autre tableau avec la liste des champs à ne pas afficher :

 {formcontrols array(),array('DATE_NAISSANCE')}
	    <p>{ctrl_label}: {ctrl_control}</p>
 {/formcontrols}

Je n'ai pas regardé les implications en terme de code, mais celà me parait raisonnablement jouable.

++ e-media

cf Ticket 353 : http://developer.jelix.org/ticket/353