![]() |
An easy solution for setting form input values for combined create/edit forms - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20) +--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23) +--- Thread: An easy solution for setting form input values for combined create/edit forms (/showthread.php?tid=18252) Pages:
1
2
|
An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]Moobies[/eluser] I have yet to find a consistent method for setting form values for updates. People seem to be manually setting values into the form validation object, e.g. Code: $this->form_validation->name = $object->name; and then in their view checking if that exists, or using their own data array passed to the view and switching on that. Code: <input name="name" value="<?php echo $this->form_validation->name ? $this->form_validation->name : $namesetindata ?>" /> Would this not be better supported by the core Form_validation class? It's quite simple: Add a function to the Form_validation class that overrides a value in the internal field data. E.g. Code: function put_value($field = null, $value = '') { Then you don't even need to change your view input code from the standard way of doing this at all ... Code: <input name="name" value="<?php echo set_value('name') ?>" /> And in your cntroller if it's an edit, you load your object and then $this->form_validation->put_value('name', $object->name); An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]TheFuzzy0ne[/eluser] There's absolutely no need to touch the form data, because set_value() accepts a second parameter which is the default to use if the form hasn't been submitted. Perhaps I'm missing something? An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]Moobies[/eluser] well, there are 2 set_values. there is the helper version and there is the form validation library version. personally, i would like to do this in my controller: Code: $this->form_validation->set_value('name', $myobj->name); and then in my view do: Code: <input type=“text” name=“name” value=”<?php echo set_value(‘name’) ?>” /> Code: $this->load->view('theformview', array('myobj' => $myobj); and then in the view Code: <input type=“text” name=“name” value=”<?php echo set_value(‘name’, $myobj->name) ?>” > however i find the former neater. and in fact, you can just put my put_value in a MY_Form_validation class to keep it out of the core. i am new to CI so you may have a better solution to that which i present ![]() An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]TheFuzzy0ne[/eluser] OK, the set_value() function is just an alias for the $this->form_validation->set_value(), but you can use whichever you want to. set_value() only returns the value of the specified field (if it exists), or the default you specified if the form hasn't been submitted. It doesn't actually "set" anything as such. If anything, it should be called "get_value". I hope this makes sense. An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]Moobies[/eluser] hi, that's fine, but it does not address the fundamental issue with its use in prepopulating form values as nicely as possible. i presented 2 alternatives above, my option, and the only other option i could think of using set_value with a default. so what do you think? in fact, the set_value with a default on a create form (i.e. with no backing object) would cause a php error, so you'd either have to check for non-null or suppress the error, e.g. Code: <input type=“text” name=“name” value=”<?php echo set_value(‘name’, @$myobj->name) ?>” > again, i think this is ugly when there is already conditional checks in the controller to determine whether a create or edit is happening. set_value in the controller does not have any influence on the form input helper version of set_value and that's because set_value is actually returning the default value from the function. my solution actually places the value in the Form_validation's internal data array so it's found by the alias helper version too. i still think my way is better unless you can convince me otherwise ![]() An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]TheFuzzy0ne[/eluser] [quote author="Moobies" date="1241118178"] in fact, the set_value with a default on a create form (i.e. with no backing object) would cause a php error, so you'd either have to check for non-null or suppress the error, e.g.[/quote] That only happens if you haven't loaded the form_validation library, or at the very least, the form helper. [quote author="Moobies" date="1241118178"] Code: <input type=“text” name=“name” value=”<?php echo set_value(‘name’, @$myobj->name) ?>” > To each his own. Personally, I think that's the best way to go. However, I'm still confused... I've seen a lot of examples, but I'm not entirely sure what you're proposing. From what I can tell, you're only proposing you change the inner workings of the method in a way that can cause problems (by messing with the postdata). It achieves the same effect, only it gives you more unpredictable results. [quote author="Moobies" date="1241118178"] set_value in the controller does not have any influence on the form input helper version of set_value and that's because set_value is actually returning the default value from the function. my solution actually places the value in the Form_validation's internal data array so it's found by the alias helper version too.[/quote] Sorry. I'm still lost... You have to set the default value regardless, to me it makes sense to be able to print an alternative if the form hasn't been submitted, and that alternative should be supplied when we're requesting the data. [quote author="Moobies" date="1241118178"] i still think my way is better unless you can convince me otherwise ![]() At the moment I'm not trying to convince anyone of anything. I'm just trying to get my head around what you're proposing. It just doesn't make any sense to me which is why I think I've misunderstood what you've said somewhere. An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]Moobies[/eluser] i started out with CI just 3 days ago so bear with me ![]() i would just like to be able to go to /objects/edit/5 and have a form load that has its fields set with the values of the record in the database. i already created the /objects/create form which if you submit with errors, returns and is prepopulated. for that i used (as the docs suggest) Code: value="<?php echo set_value('fieldname') ?>" so then i moved onto the edit side of things. to my mind, you would bind the values from the database record to the input fields in the controller. the reason for that is that all the $this->form_validation setup is done in the controller, so why not also be able to bind the record values to the view's input fields in the controller to. i found that i could not do this using any current mechanism (am i wrong?). i tried set_value (since as you say it seems to suggest that i can set the field value for the view) but it does not. the form is not yet submitted at this point, but i kind of need it to behave like it has been. this is why put_value (my "proposed" function) works, and it does not as far as i can see after testing all possibilities of submitting the forms, break or mess up anything. it's called postdata but really it's just a field to value array binding map - which is why i used it. i don't as a matter of personal taste like the fact that in my create and edit view form code (which is shared) that i have to specify the default value there and i guess that is all i am saying - is there a built-in way to specify the default value of a field for an edit form in the controller. it's not even a question, i already solved it with the put_value and it works great and keeps the view input fields tidy, so the discussion is now just a theoretical one. my view is that both ways are valid, but only your preferred way is supported which is why i added this small binding function to support my preference. does that explain? ![]() An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]TheFuzzy0ne[/eluser] I think I'm getting it, but I'd love to see a demo posted, i.e the code for view/controller/mock model/extended form_validation library. If I can see your dilemma, I think I can help a bit better. My head is quite fuzzy today, I've been doing too much thinking... However, there's nothing saying that set_value() must be used in the view. You can put it in your controller if you want to, and set the defaults there, so you'd only have something like this in your view: Code: #controller Hopefully that makes sense. Short of template parsing, I think it's impossible to keep your view any tidier. I don't see how it could be any simpler. If your requirements are different, please let me know. An easy solution for setting form input values for combined create/edit forms - El Forum - 04-30-2009 [eluser]The Wizard[/eluser] hello i create all values in an array $data['values']['input1'] = form_inpu... and when i init the form, i load them from a model, and just put <?= $values['input1'] ?> in the form. check out my 6 min tutorial you will see it there. An easy solution for setting form input values for combined create/edit forms - El Forum - 05-07-2009 [eluser]ch5i[/eluser] Hello Moobies, totally agree with you. With the pre-1.7 validation library I used prefill forms for editing like this: Controller Code: ... View Code: ... This has been working very well, and I could keep my views relatively clean. I like to have as little php as possible in the views. I wonder how this is supposed to be done 'correctly' with the new validation library...? Until something better comes up, I think I'll go with your approach. Thanks a lot for sharing. |