What's the benefit of using form helper functions?

[eluser]taewoo[/eluser]
It seems like you have to know and type much of the HTMLs anyways..
Is there a benefit to using these helper functions?

PS: This goes for HTML helpers as well.

[eluser]beemr[/eluser]
Mainly, they're for portability and consistency. The ideal is to be able to move your CI app to any domain by simply updating the config and to keep interactions in a single environment, i.e. PHP arrays.

[eluser]tomcode[/eluser]
With the right data object structure these helpers can save time, reduce code and errors and allow automatisation.

I use them where standards prime over detail.

[eluser]Sumon[/eluser]
But sometimes i prefer to use html rather then form helper . Specially when it's drop down menu where items are loaded from database.

[eluser]xwero[/eluser]
If you check out the SVN form helper you will see there are form helper functions that are connected to the validation library.
I actually use the form helper only for the form_prep function and i extended it with functions i find useful like form_post (displays posted value or default), form_selected (for select options), form_checked (for radio buttons and checkboxes), form_default (if the value is the same as the default an empty string is shown), ...

I agree with you about the html generating functions, they aren't really needed. The EL developers even added the label tag generation to the lang->line method, i still think it's a mistake because it should be handled by a helper function in my opinion.
On the other hand the html helper functions ol and ul are useful if you have a complex list to display.

You have to find out which make you develop faster and you can use the other functions if you have not much time.

[eluser]Crafter[/eluser]

Mainly, they’re for portability and consistency

You can't get more portable and consistent than HTML itself.

[eluser]Derek Allard[/eluser]
If you're comfortable with html, and the sole developer, then yeah, just use html*. But there are times when its super userful, let me give you a personal example. I want to have non-programmers handling views that have forms. I need to dynamically set form values, and maybe css classes, etc. By using a form helper, I can define the array that holds the information with any programming logic I need to in the controller, and pass it in. The view just has

Code:

<?= form_input($field_info);?>

So it stays nice and clean. I can see how this wouldn't be very advantageous in many cases, but if you've got software that say you want people to build themes for, then you'll want to keep the views as minimal as possible.

* But there is a potential technical reason. Use form_open() to declare your opening of forms. Down the road, we're hoping to get even better CSRF protection in there, and a big boost to that will come if you're using the form_open() function, so that tokens can be automatically inserted.

[eluser]Phil Sturgeon[/eluser]
CSRF is a damn good reason. Another is standards.

With (X)HTML changing over time, wouldnt it be lovely to NEVER have to worry about it? The more of your HTML is done with helpers, the less you have to recode. Instead of updating and testing every single form, you just update the helper files and you are done.

Hmm... modularization... :kiss:

[eluser]Michael Wales[/eluser]

But there is a potential technical reason. Use form_open() to declare your opening of forms. Down the road, we’re hoping to get even better CSRF protection in there, and a big boost to that will come if you’re using the form_open() function, so that tokens can be automatically inserted.

I spent all day looking for your previous posts on the forums mentioning CSRF protection (I couldn't remember what it was called!). Thanks for beating me to it Derek.

Personally, the only part of the Form helper I use is form_open() and form_close() - and primarily because of the CSRF protection that is coming down the pipeline. Plus, form_open() always ensures my routes are correct and the code would look odd if I closed that with a </form> tag...

[eluser]tomcode[/eluser]

With (X)HTML changing over time, wouldnt it be lovely to NEVER have to worry about it?

Beautiful dream, but I guess there are always changes. In fact, without changes no real progress. Maybe in a few years we'll all move from OO to something else.