Screencast: The Advanced Form Handling Series

[eluser]Colin Williams[/eluser]
Yes I do, TheoR74. I just bought proper screencasting software (no more 5 min limit!) and found I mic I think will work much better. I might even redo these 7 with the final pieces into one full screencast.

[eluser]Référencement Google[/eluser]
Personally I prefer when it is broken into 5-6 parts than a long 30 min screencast

[eluser]xwero[/eluser]
I agree with too pixel but there should be a possibility to watch the whole tutorial without interruption in a slideshow fashion.

[eluser]Colin Williams[/eluser]
Well, the benefit of now using Camtasia Studio is that I can do both. I prefer longer screencasts myself (I think these feel too hurried), but I'll certainly be able to chop it up and stitch it together at will.

[eluser]mmiranda[/eluser]
Hi, this i a wonderful tutorial, specially for me and others that are newbies here,
it should be possible to get the code?
It looks like a great starting point for a CRUD application, which i have found its the basis of most aplications
thanks again Colin.

[eluser]Colin Williams[/eluser]
I'll get the code out sooner or later.

[eluser]crumpet[/eluser]
Is it possible to make vehicle_form universal if you don't want users to be able to edit all of hte things they can decide when they create the vehicle?

[eluser]Colin Williams[/eluser]
It certainly would be possible, crumpet. So, you are talking about access control per field, correct? In order to keep the access checks out of the view, you would need to abstract out the vehicle_form view per field (one view per field or one view per type of field), and you'd probably end up with something like Drupal's Form API. I think the potential downside to this is that you give up the convenience of controlling how the form is marked up (and I guess, technically, you no long have a universal vehicle_form view, you have universal field views). So my suggestion would be to take the lesser of two apparent evils, and litter vehicle_form with the necessary checks.

Example 1

Your controller could simply unset() the fields that the user cannot access, then in vehicle_form, you need to check for the existence of a field before displaying it:

Code:

<?php if (isset($fields['model'])) : ?>
<input name="model" [...] />
<?php endif; ?>

Example 2

You could extend your form definition to include an access array which has a boolean value for each field, but you still need the check in the view, although one could argue that they read better:

Code:

<?php if (access['model']) : ?>
<input name="model" [...] />
<?php endif; ?>

I would go with Example 2 because it reads best, and unsetting form fields might have unintended consequences.

[eluser]crumpet[/eluser]
What about if in the function which returns the forms array I added another set of values called "html". And in there i put the html for each of the fields. Then i could do something like

Code:

foreach($fields AS $field){
   //may need an isset conditional here
   echo $field['html']
}

Can you anticipate any problems?

EDIT:
Nevermind i just realized this is almost identical to the first thing you proposed. My problem is a little more complex than simply needing to hide some fields. If the form is called from a certain page some of the data can be assumed. So i want to hide hte place where hte user would enter that and put it into a hidden field instead...
Suggestions??

[eluser]crumpet[/eluser]
alright i implemented this and it is way way better than what i was doing. To get what i wanted I made seperate view files for each field (lame i know) but then i was able to do this in my form's master view file.

Code:

foreach($form['fields'] as $field => $title){
    $this->load->view('front/modules/marketplace/listing_form/' . $field);
}

all i have to do to get rid of inputs is unset the field values and the rule values (so i dont get validation errors for fields that don't exist).