CSC/ECE 517 Fall 2012/ch1b 1w66 as
Forms-Ruby
Introduction
Forms in web applications are an essential interface for user input. However, form markup can quickly become tedious to write and maintain because of form control naming and their numerous attributes. Rails deals away with these complexities by providing view helpers for generating form markup.<ref>http://www.guides.rubyonrails.org/form_helpers.html</ref> Rails provides excellent features to create forms and gather user input.
Forms in Rails are an effective way to obtain user input in a convenient manner. Forms
can include different types of data fields that will help obtain different types of data. For
example, Text box can fetch a few words from the user and Text Area, a paragraph. Forms are embedded in a Web Application and are very user-friendly.
Forms in Rails also have in-built functionalities to verify the data the user enters, validate it using a set of predefined rules, display corresponding error messages(in case of non-compliance) and storing the information in the database if it passes validation.
Creating a Form
Forms written in Rails are automatically generated into HTML Forms and are rendered into views. Forms are created in Rails using the basic helper called Form_tag
<%= form_tag do %> Form contents <% end %>
When form_tag is called as above, it creates a <form> tag which, when submitted, will POST to the current page. For instance, assuming the current page is /home/index, the generated HTML will look like this (some line breaks added for readability): [1]
<form accept-charset="UTF-8" action="/home/index" method="post"> <div style="margin:0;padding:0"> <input name="utf8" type="hidden" value="✓" /> <input name="authenticity_token" type="hidden" value="f755bb0ed134b76c432144748a6d4b7a7ddf2b71" /> </div> Form contents </form>
Forms in Rails consist of Elements, which are labels, input elements, submit buttons etc.
Example of the Call Super Anti-pattern
In the example below, the super class of TestCase is extended by the TestCaseOne class. The subclass TestCaseOne calls setup at the beginning of its own setup() method and then does any extra steps.
public class TestCase{ public void setup() { ... } } public class TestCaseOne extends TestCase{ public void setup() { super.setup(); ... } }
Alternative Implementation
Instead of forcing a method to call super(), it is generally considered a better practice to use the template method pattern. In this pattern, the method that would be required to be called via super(), that method would actually call another method that is abstract has to be created by the subclass.
Example Using Alternative Implementation (Template Method Pattern)
In the example below, the super class implementation of setup() calls another method doExtraStuff() which is abstract and therefore has to be implemented by the subclass when it is extended.
public class TestCase{ public void setup() { ..... doExtraStuff(); } abstract void doExtraStuff(); } public class TestCaseOne extends TestCase{ void doExtraStuff() { ... } }
References
<references></references>