Form Validation not repopulating values that weren't in the original post

[eluser]dmorin[/eluser]
Ok, lets try another approach. Do you agree that using the POST array is the only way we know of to get the un-escaped values out of the form validation library?

OK, next, since I can't control what people are posting, being an API endpoint, I'm using callbacks to validate the data. Part of validating the data is making sure that if it's null (or not set), I set it to the values I need to. You may disagree with using the form validation library for this, but that's a matter of opinion and entirely irrelevant.

Ok, so keeping in mind the two previous points, please explain how I should retrieve the un-escaped values of each field from the form validation library.

[eluser]Colin Williams[/eluser]

Do you agree that using the POST array is the only way we know of to get the un-escaped values out of the form validation library?

I don't agree with the notion that by getting the $_POST array values we are getting values from the form validation library. But I understand what you mean. The $_POST array is where the submitted values exist, so it only makes since to get the values from there, regardless of the existence of the form validation class. The form validation class was actually designed to work this way, by laundering the $_POST array directly.

You may disagree with using the form validation library for this, but that’s a matter of opinion and entirely irrelevant.

Therein lies the problem. It is relevant. You are trying to dig a trench with a fork. Wrong tool for the job.

explain how I should retrieve the un-escaped values of each field from the form validation library

How does the fact that these values don't exist in the HTTP request keep getting ignored on your behalf? The form validation class' responsibility is to validate, filter and prepare submitted values. Your default values don't need to be validated because they are provided by the application, not the user.

Here's how I would handle default values:

Code:

// Get defaults from the object model
$default = $this->obj_model->get_defaults();

// Set rules, fields, and run validation, etc...

// If validation passes, we are going to store the new object
// The object will comprise of the validated submitted values
// and our defaults ($_POST values overwrite $default values)

$object = array_merge($default, $_POST);
$this->obj_model->save($object);

Actually, there is no point to load the defaults and merge them in the controller. This should be handled by the model.

So, I would really just send what is available in the $_POST array to the model and let it fill in the blanks. So slightly ignore the example above and move the array_merge() to the model:

Code:

// Model save() function
function save($obj)
{
  if ( !isset($obj['id']))
  {
    $obj = array_merge($this->get_defaults(), $obj);
    $this->_create($obj);
  }
  else {
    $this->_update($obj);
  }
}

[eluser]dmorin[/eluser]

Do you agree that using the POST array is the only way we know of to get the un-escaped values out of the form validation library?

You still haven't answered this.

The form validation class’ responsibility is to validate, filter and prepare submitted values.

If the form validation library is limited to submitted values, why does it run callback functions for fields that aren't present in the POST array?

Also, I'm not just using callbacks to populate the default values. In one case, either a user id or an email address is being submitted. Based on which one, I do a lookup to populate the other. If I can't populated it, then I show a validation error because the data isn't valid. Could I do it in a model, sure and then I'd have two layers of validation. Is that the best way, in my opinion, no.

[eluser]Colin Williams[/eluser]
My answer was:

I don’t agree with the notion that by getting the $_POST array values we are getting values from the form validation library. But I understand what you mean. The $_POST array is where the submitted values exist, so it only makes since to get the values from there, regardless of the existence of the form validation class. The form validation class was actually designed to work this way, by laundering the $_POST array directly.

If the form validation library is limited to submitted values, why does it run callback functions for fields that aren’t present in the POST array?

It only follows your directions. What else should it do but test against the rules you provide? If you don't want it to test against a particular rule, don't provide the rule:

Code:

if (isset($_POST['value']))
{
   // Make a rule for the 'value' field
}

In one case, either a user id or an email address is being submitted.

Again, conditionally define your rules.

[eluser]dmorin[/eluser]
Conditionally define the rules? How is that even relevant? So now, I can't set my rules in the config files, at least not in the way config files are intended to be used, my validation rules are significantly more complicated, and I still have to save the calculated values somewhere else because I can't access them through the form validation library in a standard way. Conditionally defining rules does nothing to help here and only makes things more difficult, more complicated, and you end up with the exact some problem. Did you even bother to think before writing that or are you just in this so you can argue with me as much as possible?

Stop wasting my time.

[eluser]Colin Williams[/eluser]

Did you even bother to think before writing that or are you just in this so you can argue with me as much as possible?

These threads aren't simply one-off conversations. They are archives, waiting to be searched and found by users with similar problems. It is my view that, in your frustration to solve unique application challenges, you have turned your attention to blaming a part of the framework. All I want to do is provide a dissenting view that I feel is more appropriate, so when others read this thread, they have a better idea of how to solve their own unique challenges.

If I knew all the components of your application and the exact result you were trying to achieve, I know I could suggest a method of implementation that is not at all affected by the behavior of the form validation class. We have touched on a few of these challenges in very tiny pieces, so from your view it probably just looks like an inadequate understanding on my part. And that is pretty much true. I don't adequately know the challenges of this part of your application, but I am confident that the form validation class is not buggy in the way you describe. Rather, it is the way you are trying to use the form validation class that is causing the problem.

[eluser]dmorin[/eluser]
If you are simply trying to provide an alternative for others who may stumble across this, it would have been sufficient to limit yourself to one post stating what you believe to be the better alternative. Also, describing solutions in a forum post that do not actually solve the original problem is not only off topic, but wasteful for future readers since they do not solve the problem in question and can cause more confusion than help.

I am confident that the form validation class is not buggy in the way you describe. Rather, it is the way you are trying to use the form validation class that is causing the problem.

Your view is perfectly acceptable but this is your OPINION and CI cannot be limited to function within the scope of your opinions. Your opinion that I am using the form validation class incorrectly has been noted many many times and I appreciate your input, and I respectfully disagree. Debating it further provides no value for either of us. The point of the bug post was to see if others can reproduce this issue and bring it to the attention of the CI maintainers as it is their opinion that truly matters. Because the signal to noise of this post, it will probably also fail at doing that.