server side validation blocks on checkbox in a multi page

granj1001 27 Mar, 2010
Hi,

I choose ChronoForm because it is nice features. Wizards are very useful to start quickly a form. Form code is incredible to do fine tuning.

Recently, I started a multi-page form. I came to a strange situation. To investigate, I simplify my multi page form. I got one form j1, with a 3 options check box. The server side validation does not allow option 2 to be checked (because it is incompatible with another option in the real form). If none option is checked, it's still OK. I build up another mother form j0 to do multi page (even if it does not make sense here because of simplification).

So if I call the j1 form, I could click on option 2; of course I got my alert "Option 2 not allowed!" when I submit. If I click option 2 to uncheck it and submit, the form is validated, no problem.

If I call the j0 form, and do the same, the form reappears with the same error message, and the option is checked, although I unchecked it before submitting. The only way to get out, is to select option 1 or 3 (or both). But no selection is not possible.The possibility to come back to "No selection" is an important feature for me.

If anyone could help, it would save me a lot of time.

Regards.
GreyHead 27 Mar, 2010
Hi granj1001,

It ;s late at night and I can't follow the logic of this. Can you post some pictures, or a link to the form; and the serverside validation code that you are using?

Bob
granj1001 28 Mar, 2010
Hi,

The logic may be not very clear unless we get the complete forms. The idea is that a user is registering for a conference and has got many options. Some of the combinations are not possible, and this could checked only (and seriously) by server side validation (SSV).

So a user checks option 2, but option 2 is in fact incompatible with another option in another part of the form. So SSV alerts the user on submission. Up to that point, it's OK. So the user decides to remove option 2, leaving also other options 1 and 3 unchecked. Here it becomes strange in my set-up. When user press Submit, the form is displayed again with option 2 checked and with the SSV alert. If user unchecks option 2 and checks option 3, then submission is OK. So the point is that the user could not leave all options after the SSV alert. I don't know where I am wrong.

I sent you a PM with direct links.

Regards.
nml375 28 Mar, 2010
Hi granj1001 & Bob,
I believe this is caused by a combination of issues:
[list]
  • When a child-form is republished due to an error, the old values are retrieved from the session storage. The session storage is not cleared however.

  • During submission, the previously stored values in the session storage is merged with the data available in the $_POST-array.

  • Checkboxes are only included in the submitted data when they're actually checked. When they're not submitted, there's no parameter with that name at all within the submitted data.
  • [/list]

    All this added together leads to the checkbox being "remembered" in the event of an error. I believe a workaround would be to unset the appropriate session data, as well as the $_POST data, for the checkbox in the event of an invalid selection. Something like below should do the trick, remember to replace formname (but keep the chrono_formpages_data_ prefix) and badcheckbox in the code to match your form, as well as the actual condition to detect the bad checkbox condition..
    if {invalid checkbox condition} {
      $session =& JFactory::getSession();
      $data =& $session->get('chrono_formpages_data_formname', array(), md5('chrono'));
      unset($data['badcheckbox'], $_POST['badcheckbox']);
      $session->set('chrono_formpages_data_formname', $data, md5('chrono'));
    }


    /Fredrik
    granj1001 28 Mar, 2010
    Hi Frederik,

    Impressive. The process sounds clear. The solution works perfectly. formname must be replaced by the name of the "mother" form, not the child one.

    Hope this workaround will be no more needed in further versions.
    You're definitively a specialist.

    Bob, the case is solved.

    Best regards.
    This topic is locked and no more replies can be posted.