[RÉGLÉ] Breezing forms - alimentation d'un champ caché par une variable à la soumission

[Ulyssimo]

Bonjour,

Je ne pensais pas être si rapidement de retour sur le forum après les solutions déjà apportées, mais j'ai de nouveaux états d'âmes concernant l'alimentation d'un champ caché par une variable dans un formulaire breezingforms.

J'ai maintenant expérimenté 2 solutions qui fonctionnent pour faire remonter l'identifiant de l'utilisateur connecté à l'initialisation du formulaire :

Solution 1/ : code saisi dans la zone "valeur" du champ caché :
<?php return $identifiant_joomla = JFactory::getUser()->get('username',0); ?>

Solution 2/ : code saisi en pièce de formulaire / avant formulaire
$this->execPieceByName('ff_InitLib');
$identifiant_joomla = JFactory::getUser()->get('username',0);
ff_setValue('nomdemonchampcache',$identifiant_joom la);

Tout cela marche bien.

Par contre, je voudrais faire fonctionner le code de la solution 2/ au stade de la soumission. Et là, en reprenant le même code, mais en le positionnant en soumission de pièce / début de soumission, rien ne se passe... point de 'nomdechampcaché' remontant dans les records breezingforms.
Les règles sont-elles différentes pour l'étape de soumission ?

Merci de votre aide,

Ulyssimo

[Wismer]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

pour recuperer un champ a la submission, il faut utiliser la fonction

$recup = ff_getSubmit('champ',0);

accompagner de la phrase magique.

++

[Ulyssimo]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Merci Wismer, mais je n'ai pas réussi à obtenir le résultat voulu avec cette fonction.

En fait, j'ai besoin de redéterminer l'identifiant à la soumission pour parer à un cas bien précis (cas tordu mais qui pourrait se produire) dans lequel l'utilisateur, tout en étant connecté, pourrait soumettre le formulaire en remontant la valeur "0" dans le champ caché au lieu de son identifiant :

- l'utilisateur entre dans le formulaire sans être connecté : la fonction d'entrée de formulaire (ff_setValue) alimente le champ caché avec la valeur "0" et l'utilisateur est redirigé vers la page d'identification lorsqu'il tente de soumettre
- l'utilisateur se connecte
- il a ensuite 2 options pour poursuivre :
* entrer de nouveau dans le formulaire par le lien de menu. Là, pas de problème, le formulaire est rechargé et le champ caché est alors alimenté (grâce à ff_setValue) avec son identifiant ($identifiant_joomla) puisqu'il est maintenant connecté
* retourner au formulaire chargé initialement à l'aide des flèches de retour arrière de son navigateur. Il retourne ainsi sur le formulaire initial contenant la valeur "0" dans le champ caché et peut malgré tout soumettre parce qu'il est maintenant connecté

Manque-t-il un élément pour que ça fonctionne avec la fonction $recup ? Ou faut-il procéder autrement dans mon cas de figure ?

Merci d'avance,

Ulyssimo

[Wismer]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

C'est marrant ce que tu dis, c'est exactement la solution que je t'avais propose 2 sujets plus ancien quand tu demandais comment gerer les identifiants.


Ton champ cache ne sert strictement a rien justement pour ton pb et je preconisais de recuperer la valeur de l'identifiant uniquement lors de la submission du formulaire via un bouton de type regular au debut avec la fonction javascript (validate_submit )

Dans ton begin submit, tu tapes ceci ou un truc de ce genre.

$this->execPieceByName('ff_InitLib');
$identifiant_joomla = JFactory::getUser()->get('username',0); 

if ( $identifiant_jooma == 0 ) 
   {
   ff_redirect('./index.php', 'parent', 'get');
   }
else
  {
// tes fonctions que tu mets si la personne est connectee.
  } 

Il faut juste se renseigner avec plus de detail qu'une personne deconnecte renvoie bien l'info 0 a la variable identifiant_joomla.

Tu en penses quoi d'approcher ton besoin avec cette vision?

[Ulyssimo]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Bonjour Wismer,

- J'ai bien un bouton d'envoi avec script de validation ff_validate_submit (action script faisant appel à la pièce de library correspondante).

- J'ai également le script suivant (de type "personnalisé") dans mon formulaire (la 2ème fonction me permettant de dirigier l'utilisateur vers une page de remerciements lorsqu'il a soumis avec succès) :

function ff_ID_form_submitted(status, message)
{
switch (status) {
case FF_STATUS_OK:
// do whatever desired on success
break;
case FF_STATUS_UNPUBLISHED:
case FF_STATUS_SAVERECORD_FAILED:
case FF_STATUS_SAVESUBRECORD_FAILED:
case FF_STATUS_UPLOAD_FAILED:
case FF_STATUS_ATTACHMENT_FAILED:
case FF_STATUS_SENDMAIL_FAILED:
default:
alert(message);
} // switch
} // ff_ID_form_submitted
function ff_ID_form_submitted(status, message){ff_switchpage(2);}

- Ce que tu m'indiques pour terminer est d'oublier mon champ caché et de positionner le code suivant en soumission de pièces/début de soumission ?

* 1ère partie :

$this->execPieceByName('ff_InitLib');
$identifiant_joomla = JFactory::getUser()->get('username',0);
if ( $identifiant_jooma == 0 )
{
ff_redirect('./index.php', 'parent', 'get');
}

Dans mon cas,
ff_redirect('./index.php', 'parent', 'get');
ne marche pas, mais j'avais
header("Location: index.php?option=com_comprofiler&task=login");
exit;
qui marche. Je suppose que ça doit revenir au même ?

* 2ème partie,

// tes fonctions que tu mets si la personne est connectee.

Quelle est cette fonction qui permettrait de remonter l'identifiant de l'utilisateur dans le record généré à la soumission sans passer par l'alimentation d'un champ caché ? Peux-tu préciser, mon niveau technique ne me permettant pas d'aller plus loin ?

Pour ton dernier point :

Il faut juste se renseigner avec plus de detail qu'une personne deconnecte renvoie bien l'info 0 a la variable identifiant_joomla.

En effet, la valeur 0 remonte bien pour la variable $identifiant_joomla quand l'utilisateur n'est pas connecté. C'est en tout cas ce que j'ai constaté en alimentant le champ caché avec cette variable.

Merci,

Ulyssimo

[Wismer]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Comment tu geres les enregistrements? car je pense que c'est ce point la qui decide de tout.

Comme tu tiens vraiment a ton champ cache c'est que tu utilises l'enregistrement automatique de BF qui est notoirement NUL. C'est son seul point faible.

Par contre, il a un avantage : tu peux enregistrer dans une table et je me sers constament de ca, c'est bcp plus propre et lisible.

Du coup, oubli l'enregistrement auto et passe a un enregistrement controle.

Apres, il a un autre detail que tu sembles ignorer. Il plante en version francaise ==> mets langue anglaise dans ton administration. Tu vas voir, tu vas debloquer des fonctions comme l'affichage de requete.

Ca, c'est par experience.

Sinon, tu peux garder ton champ cache et tu l'alimentes avec le begin submit par contre pour la "fin/submission" end submit, tu remets la meme fonction comme ca ta variable sera tjs a jour.

* 1ère partie :
$this->execPieceByName('ff_InitLib');
$identifiant_joomla = JFactory::getUser()->get('username',0);
if ( $identifiant_jooma == 0 )
{
ff_redirect('./index.php', 'parent', 'get');
}

Ca doit marcher si la personne est deconnectee, c'est ca qui verifie que la personne est co ou non.
Si $identifiant == 0 alors deco sinon elle est co.
Si elle est deco, je redirige.

Si cela ne marche pas, ca veut dire que tu ne passes pas par cette etape.
Desactive ta fonction function ff_ID_form_submitted. Le javascript s'execute du cote navigateur ce qui est a proscrire.
Le php s'execute cote serveur du coup, plus difficile a pirate.

[Ulyssimo]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Je n'ai pas trouvé d'option pour gérer différemment les enregistrements dans breezingforms. Si tu peux me dire où ça se passe, je suis preneuse ; ça pourra m'aider pour une prochaine fois.

J'ai quand même fini par résoudre le problème en combinant plusieurs de tes indications. Je suis parvenue à faire en sorte que l'utilisateur qui revient sur le formulaire initial à l'aide des flèches de retour arrière navigateur après sa connexion (cas où valeur du champ caché = 0 bien que l'utilisateur soit connecté), soit renvoyé sur une page lui demandant de recharger le formulaire avant de le compléter et de le soumettre.

- pièce avant formulaire inchangée :

$this->execPieceByName('ff_InitLib'); 
$identifiant_joomla = JFactory::getUser()->get('username',0); 
ff_setValue('mon-champ-cache',$identifiant_joomla); 

- pièce à la soumission :

$this->execPieceByName('ff_InitLib'); 
$identifiant_joomla = JFactory::getUser()->get('username',0); 
$recup = ff_getSubmit('mon-champ-cache',0);
if(  JFactory::getUser()->get('id',0) <= 0 )
{
    header("Location: index.php?option=com_comprofiler&task=login");
    exit;
}
elseif ( $recup == "0" )
{
   header("Location: index.php?option=com_content&view=article&id=73");
exit;
} 

index.php?option=com_comprofiler&task=login, étant mon URL de connexion
index.php?option=com_content&view=article&id=73, étant l'URL de mon article contenant le message à destination de l'utilisateur, l'invitant à repasser par le menu pour compléter le formulaire

Merci de ton aide. Mon formulaire est maintenant complètement opérationnel.

Ulyssimo

[Wismer]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Pour aller plus loin, faudrait que je saches ton niveau en mysql?

Si je te parle de "create table", "insert", "update", tu connais? Ne le prends pas mal, c'est juste pour savoir si je peux t'aiguiller vers une autre forme de stockage de donnee.

Tes headers me choquent vraiment. Normalement ca devrait marcher avec mes ff_redirect.

$this->execPieceByName('ff_InitLib'); 
$identifiant_joomla = JFactory::getUser()->get('username',0); 
$recup = ff_getSubmit('mon-champ-cache',0);
$id = JFactory::getUser()->get('id',0);
if(  $id == 0 )
   {
    $url = "/index.php?option=com_comprofiler&task=login";
    ff_redirect($url,"parent","get");
   }
elseif ( $recup == "0" )
   {
   $url = "/index.php?option=com_content&view=article&id=73";
   ff_redirect($url, "parent", "get");
   } 

En retravaillant ton code, je ne comprends tes if.
Si l'utilisateur est deconnecte par son id, je le redirige vers le page d'identification
sinon, si l'utilisateur est deconnecte par le champ cache, je le redirige vers l'article 73.

Pourquoi rediriges qqun a la page 73 si il est deco ($recup == 0 veut dire deco )? Aurai je mal compris?
En tout cas, fais attention avec les exit, c'est pas une solution pour programmer. Casser des boucles montre un pb de test et de structure.


++
Wis

[Ulyssimo]

Re : Breezing forms - alimentation d'un champ caché par une variable à la soumission

Bonjour Wismer,

Tu me parles un peu chinois concernant mysql. Donc, je pense que j'attendrai d'en avoir vraiment besoin avant de m'y mettre.

Pour le reste :
- je note qu'il faut éviter les exits. Le code que tu m'indiques devrait fonctionner sur mon site une fois en ligne. Là, je suis en local et la racine du site se décompose en 2 niveaux (http://localhost:8888/'nomdemonsite'), ce qui fait que je remonte un cran trop haut (http://localhost:8888) dans l'URL pour afficher la page html et que je suis dirigée sur une page blanche. Mais si j'ajoute manuellement le niveau manquant dans l'URL (/'nomdemonsite'), ça fonctionne.
- pour mes "if", ce qu'il faut comprendre est que l'utilisateur est bien connecté dans le "elseif" mais que je ne peux pas remonter son identifiant. On se retrouve dans ce cas de figure parce que l'utilisateur est retourné en arrière (utilisation des flèches de son navigateur), après s'être connecté, sur le formulaire qu'il avait complété avant connexion. Et dans ce formulaire initial, le champ caché était renseigné à 0. Il est donc nécessaire qu'il recharge de nouveau le formulaire après sa connexion pour alimenter le champ caché avec son identifiant. C'est ce que je lui indique de faire dans l'article 73 sur lequel je le redirige.

Merci pour ton aide.
Je passe le sujet en "réglé".

Ulyssimo