
Live View Implementation
Problem
I would like to give users the opportunity to quickly view the data during the editing process so that it does not turn out that after sending from the form the data appears in a damaged format (when it comes, for example, to a diary entry that they are going to put on public display).
Solution
Live browsing is easy with the built-in Rails JavaScript helpers. For this recipe, we will manage to create a quick view of the simplest form designed to create a diary entry.
First of all, when creating any Rails effect related to the use of Ajax, you need to ensure that the necessary JavaScript libraries are included in the code. To achieve the effect of online viewing, you need to include only one library - Prototype. I recommend doing this in the main application template (in our case, in the layouts / standard.rhtml file):
Now that you have loaded the required JavaScript libraries, you need to create a model and controller that will support the entry of diary entries. We will call the Entry model class, passing it the title and body properties. If you want to continue working without defining the corresponding Active Record table, then the app / models / entry.rb file should take the following form:
The controller will be called DiaryController. We will create it in the file app / control-lers / diary_controller.rb. Let's stick to the basics, and call the action to create a new record new ():
Now it’s the turn of the function itself. In the performance created for this action, all our magic will be created. Create the file app / views / diary / new.rhtml and give it the following form:
We created a standard, universal form with an id that has an entry-form value, so it can be referenced from the rest of the code. The definition of the form is followed by a call to the observe_form () helper, which generates the required JavaScript code to poll each form element displayed on the page (referring to it by id) and search for changes. The poll will be conducted at time intervals (in seconds) specified by the frequency parameter. As soon as changes are noticed, a call will be sent to the URL defined by the parameter: url, to which form data will be passed as parameters. The: update parameter defines the HTML element (again by its id) that will be updated with the results of the URL call. In this case, the content of the element that is used for online viewing will be updated by
To make the live view element invisible when the page was first loaded, we used the built-in CSS. Until the user enters any data, there will be nothing to show in the live view item. The: complete parameter, passed to the observe_form () helper, instructs after completion of the call to the preview () action to execute a JavaScript fragment that will enable the display of the live preview element.
If in operational viewing it is necessary to display only one field, then we can use the observe_field () helper instead.
Now it remains only to ensure the execution of the preview () action. Here is his code taken from the controller:
The only task performed by the action code is to “short-circuit” the usual data sending scheme used in the application. Since we are going to update the live view element on the page for creating daily diary entries and use only the results returned by the preview () action for this, we do not need to return the entire HTML page. We only need an excerpt that has a certain meaning in the composition of the more voluminous contents of the screen.
The view intended for the preview () action is in the file app / views / diary / preview.rhtml and should look like this:
That's all! This view uses an HTML header to name the record, and then, using the textilize () method, generates HTML output. Inside this method, the RedCloth library is used to convert plain text markup to HTML.
Now you can download the diary entry form and see how plain text is converted to HTML before you click on the Save button. PS

The frequency parameter used in the observe_field () and observe_form () methods can be set to zero or negative, which will lead to a real-time overview of the field. It would seem that there might be a bad thing in the instant reaction of the user interface, but in fact it will be suppressed, not to mention the additional heavy load on the servers. When tracking changes in real time, each change will cause a request to be sent to the server, from which you need to wait for the result to see the update on the screen. Changes are queued, as a result of which live-view updates slowly follow them, waiting for the next interception.
Crosspost from my P.S. blog
Yes, please, if something is not clear to you - write in comments. Stop minus karma for topics that seem to (IMHO) carry useful information.
I would like to give users the opportunity to quickly view the data during the editing process so that it does not turn out that after sending from the form the data appears in a damaged format (when it comes, for example, to a diary entry that they are going to put on public display).
Solution
Live browsing is easy with the built-in Rails JavaScript helpers. For this recipe, we will manage to create a quick view of the simplest form designed to create a diary entry.
First of all, when creating any Rails effect related to the use of Ajax, you need to ensure that the necessary JavaScript libraries are included in the code. To achieve the effect of online viewing, you need to include only one library - Prototype. I recommend doing this in the main application template (in our case, in the layouts / standard.rhtml file):
<% = javascript_include_tag "prototype"%>
...
* This source code was highlighted with Source Code Highlighter .
Now that you have loaded the required JavaScript libraries, you need to create a model and controller that will support the entry of diary entries. We will call the Entry model class, passing it the title and body properties. If you want to continue working without defining the corresponding Active Record table, then the app / models / entry.rb file should take the following form:
class Entry
attr_accessor: title,: body
end * This source code was highlighted with Source Code Highlighter .
The controller will be called DiaryController. We will create it in the file app / control-lers / diary_controller.rb. Let's stick to the basics, and call the action to create a new record new ():
def new
entry = Entry.new
end * This source code was highlighted with Source Code Highlighter .
Now it’s the turn of the function itself. In the performance created for this action, all our magic will be created. Create the file app / views / diary / new.rhtml and give it the following form:
<% form_tag ({: action => "save"},: id => "entry-form") do%>
<% = text_field: entry,: title%>
<% = text_area: entry,: body%>
< % = submit_tag “Save”%>
<% end -%>
<% = observe_form “entry-form”,:
frequency => 2 ,:
update => “live-preview”
,: complete => “Element.show (' live-preview ') ",
: url => {: action =>" preview "}%>
* This source code was highlighted with Source Code Highlighter .
We created a standard, universal form with an id that has an entry-form value, so it can be referenced from the rest of the code. The definition of the form is followed by a call to the observe_form () helper, which generates the required JavaScript code to poll each form element displayed on the page (referring to it by id) and search for changes. The poll will be conducted at time intervals (in seconds) specified by the frequency parameter. As soon as changes are noticed, a call will be sent to the URL defined by the parameter: url, to which form data will be passed as parameters. The: update parameter defines the HTML element (again by its id) that will be updated with the results of the URL call. In this case, the content of the element that is used for online viewing will be updated by
To make the live view element invisible when the page was first loaded, we used the built-in CSS. Until the user enters any data, there will be nothing to show in the live view item. The: complete parameter, passed to the observe_form () helper, instructs after completion of the call to the preview () action to execute a JavaScript fragment that will enable the display of the live preview element.
If in operational viewing it is necessary to display only one field, then we can use the observe_field () helper instead.
Now it remains only to ensure the execution of the preview () action. Here is his code taken from the controller:
def preview
render: layout => false
end * This source code was highlighted with Source Code Highlighter .
The only task performed by the action code is to “short-circuit” the usual data sending scheme used in the application. Since we are going to update the live view element on the page for creating daily diary entries and use only the results returned by the preview () action for this, we do not need to return the entire HTML page. We only need an excerpt that has a certain meaning in the composition of the more voluminous contents of the screen.
The view intended for the preview () action is in the file app / views / diary / preview.rhtml and should look like this:
Preview:
<% = params [: entry] [: title]%>
<% = textilize params [: entry] [: body]%>
* This source code was highlighted with Source Code Highlighter .
That's all! This view uses an HTML header to name the record, and then, using the textilize () method, generates HTML output. Inside this method, the RedCloth library is used to convert plain text markup to HTML.
Now you can download the diary entry form and see how plain text is converted to HTML before you click on the Save button. PS

The frequency parameter used in the observe_field () and observe_form () methods can be set to zero or negative, which will lead to a real-time overview of the field. It would seem that there might be a bad thing in the instant reaction of the user interface, but in fact it will be suppressed, not to mention the additional heavy load on the servers. When tracking changes in real time, each change will cause a request to be sent to the server, from which you need to wait for the result to see the update on the screen. Changes are queued, as a result of which live-view updates slowly follow them, waiting for the next interception.
Crosspost from my P.S. blog
Yes, please, if something is not clear to you - write in comments. Stop minus karma for topics that seem to (IMHO) carry useful information.