A Ruby on Rails Gem for DRY input forms

Frameworks such as Ruby on Rails can be a real boon to software developers by encouraging a convention-over-configuration approach to implementation. This expedites the development process by abstracting away levels of detail that would bring development to a crawl should a team otherwise need to implement.

Ruby on Rails follows tropes that are expected of a Model-View-Controller implementation. A scaffold command will build the necessary skeleton to support the interaction between these components.

Generating a scaffold of User, for example, will put into place a model where data validation pertaining to the attributes of a User occurs. A Users controller is also created and a set of methods are stubbed. The stubbed methods are indicative of common software patterns inviting a developer to create the logic to support these patterns. What needs to be done to create a new user? How exactly does a user update their information? If applicable, should we provide a list of users as an index? These are the types of questions that are answered and implemented within the methods of a generated controller.

The major component which produces the interface in which a visitor interacts with is the onus of the view component within the Model-View-Controller. The Ruby on Rails framework provides a set of helper methods to speed along the development of these views. Need a the production of a text input tag? Instead of implementing a template of a specific HTML element, just run a call to the text_tag or text_field helper method. Need a label to accompany this input? Instead of typing <label for="user_name">Please provide a name</label>, just call the label helper method which accepts the required attributes as arguments. This provides the advantage of decoupling tedious detail from what's important.

Consider the basic example of the following form:

In terms of view helper methods which produce the user interface: label, text_field, and button_tag are all being used. This should equate to three lines of code, right?

Things become complicated once a developer factors failed validation. Upon submit, the following is displayed:

To maintain the text of test#example[dot]com within the text input element requires a set of conditionals which evaluate whether this value needs to be considered. The error label displaying Invalid email given also needs its own group of logic. The code required may look like this:

This can become quite cumbersome, especially as forms grow in size. Imagine if this submission form required a user to supply a first-name, a last-name, a phone-number, etc. This would cause the required logic to balloon in size. This goes against the grain of decoupling tedium from what's important.

To address this, I've been building, (and have since published), a new Ruby Gem which abstracts away this pattern into something much more clean and easier to digest at a glance:

The result of implementing this is something that more closely adheres to the motivating ideology of MVC frameworks such as Ruby on Rails.

To use this gem, one needs to simply include form_input_field within their gemfile and run bundle install. This will give access to two primary methods: form_input_field and form_error_field.

form_input_field acts as a wrapper for the group of logic which presents the initial input tag and its label. It also handles the conditional logic required for maintaining any value that should be remembered in presenting the input should a post fail. Generally speaking, the set of arguments are as follows:

form_input_field(helper_sym, object_name, method, label_text = false, options = {}, label_options = {}, value_key = :values)        

The helper_sym argument corresponds to a symbol which has a namesake for any helper method which produces an interactive element within ActionView::Helpers::FormHelper. If one wants a text_field production, then supply a value of :text_field; If one wants an email_field production, then supply a value of email_field, etc.

The object_name and method arguments follow the same form as any of the aforementioned helper methods within the FormHelper module. label_text corresponds with the textual content with the associated label. The value for the options argument corresponds to the set of options associated with the associated production of the helper_sym html element. This is while the value for the label_options argument corresponds to the set of options associated with the label html element.

This leaves the value_key argument which is a key to the flash hash-map that points to a value to be placed in the input element's value attribute - allowing the input element to be pre-filled. form_input_field expects the value associated with this key to either be a string or a hash-map. If it is a hash-map, then it will use value given for the method argument as its key to find a string. For example:

The form_error_field helper method follows the same pattern. It differs in the sense that it is responsible for outputting a single label dependent on the presence of a value for an error_key keyword argument. A generalized call to form_error_field is as such:

form_error_field(object_name, method, label_options = {}, error_key = :errors)        

What made this fun to implement was working with Ruby's expressiveness and means of introspection. Those who know how to program will find it interesting that the following statement produces a true:

"Hello" + "World!" == "Hello".+("World!") and
"Hello".+("World!") == "Hello".send(:+, "World!")        

This facet may clue one into what's happening with the helper_sym parameter. To get a closer feel for the logic contained within these helper methods, take a look at the technical writing Ruby on Rails: Developing Dry Forms which also explains the motivations and process of deciding which components to abstract from the initial set of methods contained in the FormHelper ActionView module.

More in-depth documentation for how to use this gem is also located on my personal site within a technical writing labeled Ruby Gem: form_input_field. Here, one can find a more detailed description of the methods' parameters with a wider set of examples. The gem itself is located at https://rubygems.org/gems/form_input_field.

Among documentation is a change-log along with a list of features to be implemented as development continues on this project. These features are:

• A mechanism to set flash key defaults.
• An extension of this gem to include compatibility with ActionView::Helpers::FormBuilder.
• Create function wrappers specific to the required FormHelper method. I.e., form_text_field(:model, :object_name) which calls form_input_field(:text_field, :model, :object_name)

Implementation of the last bullet item will push this gem into a version 1.0.0 release. Any other feature suggestions are welcome within the issues page of the source code repository.

The motives of creating this gem align with the motives of frameworks such as Ruby on Rails. The result of leveraging the provided helper methods allows the programmatic statements within a view to be easier to digest at a glance. If you're a Ruby on Rails developer, give it a try and let me know whether you agree!