Only seems more complicated and a total overkill. Reminds me of Zend Framework (php) where you would need to write 60 loc to add a simple form with two fields.
As a Zend Framework refugee, I agree. View stuff belongs in the view.
Additionally, for those of us who works with designers, this gets in the way. My designer-colleague is comfortable editing HAML by now; I want to give him the templates and let him move things around without having to involve me for things like where a label should be.
nice post, which demystified FormBuilder a bit for me. (yes, simple_form is awesome, but the minute you try to do something nonstandard (e.g. bootstrap3 compatibility) you have to fight with it very hard and it becomes just another leaky abstraction).
I think there are many benefits in decoupling this form presentation logic vs plain view further with form builder compared to some gems. The ability to work with the form, create your own fields, and use presentation logic outside of the form view is great. And now knowing it's built in to rails, this is fantastic (and it's also good to know I don't always have to go to other form builder gems for their conciseness when I want that and control).
Awesome. I usually don't see anyone understanding the necessity of dynamic form building.
In this case, you could easily get a form declaration from a database or another file, go through your controller (or form builder class) to translate it and add the correct parameters.
For those that don't get why you'd need to do that, here are some examples:
* creating forms in multiple languages (the form controller can take care of content/labeling/placeholders)
* creating forms to comply in multiple countries (for example, the same sign up form in Europe may require a "accept cookies when I'm on site" checkbox or something similar).
* creating forms based on preselected options. For instance, if a user is signing up for a free account, they won't need to give their name. While a paid account (by necessity of billing) will require credit card info.
I really wanted to avoid going in a discussion between gems trying to replace FormBuilder but I feel there needs to be some clarification.
I have used simple_form, and I have used many different gems in the past. Simply saying that using simple_form solves every issues completely misses the point.
There's a lot of forms out there that are built dynamically that needs a lot of conditions and evaluations to build the gems. CSS class can be added/removed depending on the current status of the user. This kind of things CANNOT be easily done with simple_form.
For example, what if I need to add a class to the form if the user is an admin? Would you create a helper method for that? Or a ternary condition?
If I mentioned simple_form in the very beginning of the article, it's possible that I did it so I would avoid this kind of facile counter-argument. I guess I was wrong.
It's a toolbox, each gem has unique strengths and weaknesses.
If using ActiveAdmin, it's likely that large projects that include external apps already require simpleform and/or formtastic in addition to form_for/formbuilder.
Whatever works best for a given situation / is easiest / most maintainable gets my vote.
11 comments
[ 5.2 ms ] story [ 40.5 ms ] threadAdditionally, for those of us who works with designers, this gets in the way. My designer-colleague is comfortable editing HAML by now; I want to give him the templates and let him move things around without having to involve me for things like where a label should be.
In this case, you could easily get a form declaration from a database or another file, go through your controller (or form builder class) to translate it and add the correct parameters.
For those that don't get why you'd need to do that, here are some examples:
* creating forms in multiple languages (the form controller can take care of content/labeling/placeholders) * creating forms to comply in multiple countries (for example, the same sign up form in Europe may require a "accept cookies when I'm on site" checkbox or something similar). * creating forms based on preselected options. For instance, if a user is signing up for a free account, they won't need to give their name. While a paid account (by necessity of billing) will require credit card info.
Really cool :)
I have used simple_form, and I have used many different gems in the past. Simply saying that using simple_form solves every issues completely misses the point.
There's a lot of forms out there that are built dynamically that needs a lot of conditions and evaluations to build the gems. CSS class can be added/removed depending on the current status of the user. This kind of things CANNOT be easily done with simple_form.
For example, what if I need to add a class to the form if the user is an admin? Would you create a helper method for that? Or a ternary condition?
If I mentioned simple_form in the very beginning of the article, it's possible that I did it so I would avoid this kind of facile counter-argument. I guess I was wrong.
If using ActiveAdmin, it's likely that large projects that include external apps already require simpleform and/or formtastic in addition to form_for/formbuilder.
Whatever works best for a given situation / is easiest / most maintainable gets my vote.