Form Validation - set_value() working differently in v3 |
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 : ''; ?> 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.
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!
"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.
(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.
(05-03-2015, 09:21 AM)ivantcholakov Wrote: @sparky672 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?
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.
(05-03-2015, 09:38 AM)sparky672 Wrote:(05-03-2015, 09:21 AM)ivantcholakov Wrote: @sparky672 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. (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. (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. 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. 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. |
Welcome Guest, Not a member yet? Register Sign In |