Welcome Guest, Not a member yet? Register   Sign In
Form Validation Class - Get validated values?
#11

[eluser]dmorin[/eluser]
@CroNiX
Very true. I'm not just setting a default value. What I'm doing is, if an email address field isn't provided/entered, I looking up the email address in my system based on other fields that are submitted. So it's a little more complicated than just adding a default value.

@Colin Williams
Doing what you suggested won't do anything unless the conditional surrounding it that checks if the key is already set in the post array is also removed. To understand why I'm "injecting" data into the POST, think about an API where some fields are optional. When people post to the API, they'll only include the fields they're interested in, leaving off the optional ones. So, if you need to do anything with those optional fields to validate the incoming parameters, it won't be possible to get those fields from the validation class.

I'm not really looking for work-arounds since I can come up with plenty on my own. I now believe this is a bug which is why I asked that it be move to the bug forum. Thanks
#12

[eluser]dmorin[/eluser]
I created a bug post at http://ellislab.com/forums/viewthread/107839/
#13

[eluser]Colin Williams[/eluser]
So, you contend that the bug is
Quote:If you define a field to be validated using the form validation library and it isn’t included in the $_POST array, the form validation library will still validate it including running any callback functions, but will not add the processed value back into the $_POST array at the completion of the validation.

I still can't fathom how a "processed" value comes from a value that never existed. But regardless of that, what is the expected behavior? What should the validation class do?
#14

[eluser]rlaskey[/eluser]
[quote author="dmorin" date="1236369733"]@CroNiX
Very true. I'm not just setting a default value. What I'm doing is, if an email address field isn't provided/entered, I looking up the email address in my system based on other fields that are submitted. So it's a little more complicated than just adding a default value.

@Colin Williams
Doing what you suggested won't do anything unless the conditional surrounding it that checks if the key is already set in the post array is also removed. To understand why I'm "injecting" data into the POST, think about an API where some fields are optional. When people post to the API, they'll only include the fields they're interested in, leaving off the optional ones. So, if you need to do anything with those optional fields to validate the incoming parameters, it won't be possible to get those fields from the validation class.

I'm not really looking for work-arounds since I can come up with plenty on my own. I now believe this is a bug which is why I asked that it be move to the bug forum. Thanks[/quote]

I'm not sure if I'm hearing you right, though it seems that you're trying to pre-populate a field without the source of the data being from POST. I have a similar situation that I've dealt with in trying to pre-populate a form for an "edit" page. There is already data in the DB and there was not an initial POST, but I wanted to still use the set_checkbox() and other similar functions, since they seem to work pretty well. What I did was something like:

Code:
$attending_checked = array(2,3); // for simplicity; actual values derived via DB query/etc.
$this->form_validation->_field_data['attending[]'] = array('postdata' => $attending_checked);

It's probably not the best way to go about it, as it assumes that whatever data is in the DB / grabbing routines is clean, and is subverting some utility in the form validation library / form helper functions.. though it seems to work OK for me, and it gets the field data pre-populated properly.

If I am breaking protocol here, or if there are better, more accepted ways to go about this sort of thing, then please shout out. I don't, however, believe that there is necessarily a bug in the current system; more that there is included functionality which is not as explicit when it comes to this sort of situation.
#15

[eluser]dmorin[/eluser]
In your case, it may be better to use the last parameter of the helper functions to set the default value, which will be used since the values don't exist in the POST array.
#16

[eluser]rlaskey[/eluser]
[quote author="dmorin" date="1236484683"]In your case, it may be better to use the last parameter of the helper functions to set the default value, which will be used since the values don't exist in the POST array.[/quote]

Right. This may be how I set things up in this case in the future. I'm using the page as a create / edit page, which is part of the reason I wanted to go the way that I did. There are a lot of cases to handle, and I found the above to be the most compact way of getting what I wanted.

My main point, however, was about the importance of the $this->form_validation->_field_data array. This is a rather hidden variable, but is a fundamental part of the form_validation class and the built-in CI form helpers. By supplying information into $this->form_validation->_field_data instead of POST, you may be able to get the result that you want. There may not be explicit functions in handling this variable the way you want, though this does not mean that there is necessarily a bug in the form validation class.
#17

[eluser]dmorin[/eluser]
Ah, I see what you mean and I agree that accessing _field_data directly can be useful for interacting with the form validation library. However, for php4 compatibility, CI prefixes things with _ to indicate that they should be private in nature, and accessing the private components of a class in order to get it to behave the way you need violates some oo principles such as encapsulation.

It is odd though that the helpers reference this array instead of using setters and getters. Not the best bit of code IMHO.
#18

[eluser]rlaskey[/eluser]
[quote author="dmorin" date="1236551195"]Ah, I see what you mean and I agree that accessing _field_data directly can be useful for interacting with the form validation library. However, for php4 compatibility, CI prefixes things with _ to indicate that they should be private in nature, and accessing the private components of a class in order to get it to behave the way you need violates some oo principles such as encapsulation.

It is odd though that the helpers reference this array instead of using setters and getters. Not the best bit of code IMHO.[/quote]

Right, exactly. This is in part what I mean by a lack of functionality, rather than a bug. For future versions of CI it would help, I think, to have some alternate functions which provide access to this private variable via different methods. The current scheme is fairly limited to POST data coming in, processing it, and then spitting the result straight back out. If there are other sources, which is essentially what you'd like to implement, the current functions are too restrictive to allow incoming information unless you access this private variable rather directly.

Currently, there is the vehicle to extend libraries using your own functions, etc., and this may be the right way around the solution. In future versions of CI, however, it'd be nice to see some of this functionality included in the core. Something like a MY_Form_validator.php, w/ a function something like add_nonpost_variable_and_run() .. if that makes sense. This function would access the private _field_data variable, tack on whatever variables you'd like to the array (i.e., the email address from the DB that you pull out) formatted by way that complies with the standard _field_data, and then run the validations to make sure everything checks out.




Theme © iAndrew 2016 - Forum software by © MyBB