• 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Form Validation - set_value() working differently in v3

#1
I'm using CodeIgniter v3 on a new project and noticed that Form Validation in conjunction with set_value() is not working the same as it did in CodeIgniter v2.

In CI version 3, set_value() is totally ignoring an empty string on a "required" validation error, where CI v2 did not.

The scenario is a form that can be used to "edit" existing data.  The page loads with the form fully populated with data.  Let's say every field is already set as "required".

Consider the following code...

Code:
<?php $first = isset($first) ? $first : ''; ?>
<input type="text" name="first" value="<?php echo set_value('first', $first); ?>" />

In CodeIgniter v2: if you blank out a few fields and hit submit, when the page reloads, you'll see validation errors, and the blanked out fields remain blank until you fix them.

In CodeIgniter v3: if you blank out a few fields and hit submit, when the page reloads, you'll see validation errors, but the blanked out fields reload with their original values; not blank as expected.
  • It's not a programming error... if you generate other kinds of validation errors, the page reloads and shows the newly entered data.
  • This data is not yet saved to the database.  It's just what is shown when the page reloads on validation errors.

So with the "required" rule on an empty field, set_value() simply ignores the empty string and reverts to the original value on a failed validation reload.  Under CI v2 it would load with the empty string (blank field) on a failed validation.

Is this new behavior an intentional or is this a bug?

The v3 documentation for set_value() is the same as v2

Thank-you!
Reply

#2
"In CodeIgniter v3: if you blank out a few fields and hit submit, when the page reloads, you'll see validation errors, but the blanked out fields reload with their original values; not blank as expected."

You are right, this behavior in CI3 is a mistake.
Reply

#3
https://github.com/bcit-ci/CodeIgniter/issues/3816
Reply

#4
(04-29-2015, 04:22 PM)ivantcholakov Wrote: https://github.com/bcit-ci/CodeIgniter/issues/3816

Thanks for confirming.  However, I applied the code change described at Github to my source file and it does not make any difference.  The problem continues.

EDIT:

Although the problem now only occurs when the name of the field is part of an indexed array. "name[1]", etc.
Reply

#5
@sparky672

I have no time to look at the "name[1]" case, just I can propose a blind guess. If you take the code of the method
Code:
protected function _reduce_array($array, $keys, $i = 0)
from CodeIgniter 2.2 and replace with it the same method in CI 3, what would happen?
Reply

#6
(05-03-2015, 09:21 AM)ivantcholakov Wrote: @sparky672

I have no time to look at the "name[1]" case, just I can propose a blind guess. If you take the code of the method


Code:
protected function _reduce_array($array, $keys, $i = 0)
from CodeIgniter 2.2 and replace with it the same method in CI 3, what would happen?

I don't know... but I can try it tomorrow.  Thank-you!

Earlier today, I verified that this "name[1]" case is working fine in CI v2; it's just an issue in CI v3.

I actually coded a simple a workaround that looks at the post array and avoids the issue entirely by not using "set_value()".  Although, that does everyone else no good when the root bug persists in v3.

Meanwhile, trying to get somebody on the GitHub thread to take this seriously has been a challenge.  First he told me that I "don't have the same problem".  Then when I created a demo that reproduces the same problem, he says that "it's not designed to work like you want it to".  Just seems like a lot of shooting from the hip over there. Is the team serious about fixing bugs or not?
Reply

#7
I have just tried the guess with fragments of your code. In my platform the old method's code (from CI2.2) fixes the "name[1]" case.
Reply

#8
(05-03-2015, 09:38 AM)sparky672 Wrote:
(05-03-2015, 09:21 AM)ivantcholakov Wrote: @sparky672

I have no time to look at the "name[1]" case, just I can propose a blind guess. If you take the code of the method



Code:
protected function _reduce_array($array, $keys, $i = 0)
from CodeIgniter 2.2 and replace with it the same method in CI 3, what would happen?

I don't know... but I can try it tomorrow.  Thank-you!

Earlier today, I verified that this "name[1]" case is working fine in CI v2; it's just an issue in CI v3.

I actually coded a simple a workaround that looks at the post array and avoids the issue entirely by not using "set_value()".  Although, that does everyone else no good when the root bug persists in v3.

Meanwhile, trying to get somebody on the GitHub thread to take this seriously has been a challenge.  First he told me that I "don't have the same problem".  Then when I created a demo that reproduces the same problem, he says that "it's not designed to work like you want it to".  Just seems like a lot of shooting from the hip over there.  Is the team serious about fixing bugs or not?

You don't have the same problem as the OP did.
It's not designed to work like you want it to.
It's not a bug as far as I'm concerned.
Reply

#9
(05-03-2015, 10:04 AM)Narf Wrote: You don't have the same problem as the OP did.

Yet the steps to reproduce are the same.

(05-03-2015, 10:04 AM)Narf Wrote: It's not designed to work like you want it to.

Like I want? I'm only asking about the behavior that we had in version 2, that's now missing from v3.
Reply

#10
(05-03-2015, 10:14 AM)sparky672 Wrote:
(05-03-2015, 10:04 AM)Narf Wrote: You don't have the same problem as the OP did.

Yet the steps to reproduce are the same.


No, they are not. You're using an array notation field name, with a specific index.

(05-03-2015, 10:14 AM)sparky672 Wrote:
(05-03-2015, 10:04 AM)Narf Wrote: It's not designed to work like you want it to.

Like I want?  I'm only asking about the behavior that we had in version 2, that's now missing from v3.

There are ~20 bug fixes in CI3's Form validation compared to CI2, some of them related to how arrays are treated. Have you considered that the behavior that you want may've been a side-effect of a bug?

I can only tell you one thing - 'foo[1]' (or any array notation field name with a specific numeric index) has never been considered as a possible use case.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.