Module: ActionView::Helpers::PrototypeHelper

Module | ActionView::Helpers::PrototypeHelper
In: | lib/action_view/helpers/prototype_helper.rb

Provides a set of helpers for calling Prototype JavaScript functions, including functionality to call remote methods using Ajax. This means that you can call actions in your controllers without reloading the page, but still update certain parts of it using injections into the DOM. The common use case is having a form that adds a new element to a list without reloading the page.

To be able to use these helpers, you must include the Prototype JavaScript framework in your pages. See the documentation for ActionView::Helpers::JavaScriptHelper for more information on including the necessary JavaScript.

See link_to_remote for documentation of options common to all Ajax helpers.

See also ActionView::Helpers::ScriptaculousHelper for helpers which work with the Scriptaculous controls and visual effects library.

See JavaScriptGenerator for information on updating multiple elements on the page in an Ajax response.

### Methods

build_callbacks build_observer evaluate_remote_response form_remote_for form_remote_tag link_to_remote method_option_to_s observe_field observe_form options_for_ajax periodically_call_remote remote_form_for remote_function submit_to_remote update_element_function update_page update_page_tag

### Constants

CALLBACKS | = | Set.new([ :uninitialized, :loading, :loaded, :interactive, :complete, :failure, :success ] + (100..599).to_a)
AJAX_OPTIONS | = | Set.new([ :before, :after, :condition, :url, :asynchronous, :method, :insertion, :position, :form, :with, :update, :script ]).merge(CALLBACKS)

### Public Instance methods

evaluate_remote_response()

Returns ‘eval(request.responseText)’ which is the JavaScript function that form_remote_tag can call in :complete to evaluate a multiple update return document using update_element_function calls.

form_remote_for(object_name, *args, &proc)

Alias for remote_form_for

form_remote_tag(options = {})

Returns a form tag that will submit using XMLHttpRequest in the background instead of the regular reloading POST arrangement. Even though it‘s using JavaScript to serialize the form elements, the form submission will work just like a regular submission as viewed by the receiving side (all elements available in `params`). The options for specifying the target with :url and defining callbacks is the same as link_to_remote.

A "fall-through" target for browsers that doesn‘t do JavaScript can be specified with the :action/:method options on :html.

Example:

      form_remote_tag :html => { :action =>
        url_for(:controller => "some", :action => "place") }

The Hash passed to the :html key is equivalent to the options (2nd) argument in the FormTagHelper.form_tag method.

By default the fall-through action is the same as the one specified in the :url (and the default method is :post).

link_to_remote(name, options = {}, html_options = {})

Returns a link to a remote action defined by `options[:url]` (using the url_for format) that‘s called in the background using XMLHttpRequest. The result of that request can then be inserted into a DOM object whose id can be specified with `options[:update]`. Usually, the result would be a partial prepared by the controller with either render_partial or render_partial_collection.

Examples:

      link_to_remote "Delete this post", :update => "posts",
        :url => { :action => "destroy", :id => post.id }
      link_to_remote(image_tag("refresh"), :update => "emails",
        :url => { :action => "list_emails" })

You can also specify a hash for `options[:update]` to allow for easy redirection of output to an other DOM element if a server-side error occurs:

Example:

      link_to_remote "Delete this post",
        :url => { :action => "destroy", :id => post.id },
        :update => { :success => "posts", :failure => "error" }

Optionally, you can use the `options[:position]` parameter to influence how the target DOM element is updated. It must be one of `:before`, `:top`, `:bottom`, or `:after`.

By default, these remote requests are processed asynchronous during which various JavaScript callbacks can be triggered (for progress indicators and the likes). All callbacks get access to the `request` object, which holds the underlying XMLHttpRequest.

To access the server response, use `request.responseText`, to find out the HTTP status, use `request.status`.

Example:

      link_to_remote word,
        :url => { :action => "undo", :n => word_counter },
        :complete => "undoRequestCompleted(request)"

The callbacks that may be specified are (in order):

`:loading`: | Called when the remote document is being loaded with data by the browser.
`:loaded`: | Called when the browser has finished loading the remote document.
`:interactive`: | Called when the user can interact with the remote document, even though it has not finished loading.
`:success`: | Called when the XMLHttpRequest is completed, and the HTTP status code is in the 2XX range.
`:failure`: | Called when the XMLHttpRequest is completed, and the HTTP status code is not in the 2XX range.
`:complete`: | Called when the XMLHttpRequest is complete (fires after success/failure if they are present).

You can further refine `:success` and `:failure` by adding additional callbacks for specific status codes.

Example:

      link_to_remote word,
        :url => { :action => "action" },
        404 => "alert('Not found...? Wrong URL...?')",
        :failure => "alert('HTTP Error ' + request.status + '!')"

A status code callback overrides the success/failure handlers if present.

If you for some reason or another need synchronous processing (that‘ll block the browser while the request is happening), you can specify `options[:type] = :synchronous`.

You can customize further browser side call logic by passing in JavaScript code snippets via some optional parameters. In their order of use these are:

`:confirm`: | Adds confirmation dialog.
`:condition`: | Perform remote request conditionally by this expression. Use this to describe browser-side conditions when request should not be initiated.
`:before`: | Called before request is initiated.
`:after`: | Called immediately after request was initiated and before `:loading`.
`:submit`: | Specifies the DOM element ID that‘s used as the parent of the form elements. By default this is the current form, but it could just as well be the ID of a table row or any other DOM element.

observe_field(field_id, options = {})

Observes the field with the DOM ID specified by `field_id` and makes an Ajax call when its contents have changed.

Required `options` are either of:

`:url`: | `url_for`-style options for the action to call when the field has changed.
`:function`: | Instead of making a remote call to a URL, you can specify a function to be called instead.

Additional options are:

`:frequency`: | The frequency (in seconds) at which changes to this field will be detected. Not setting this option at all or to a value equal to or less than zero will use event based observation instead of time based observation.
`:update`: | Specifies the DOM ID of the element whose innerHTML should be updated with the XMLHttpRequest response text.
`:with`: | A JavaScript expression specifying the parameters for the XMLHttpRequest. This defaults to ‘value’, which in the evaluated context refers to the new field value. If you specify a string without a "=", it‘ll be extended to mean the form key that the value should be assigned to. So :with => "term" gives "’term’=value". If a "=" is present, no extension will happen.
`:on`: | Specifies which event handler to observe. By default, it‘s set to "changed" for text fields and areas and "click" for radio buttons and checkboxes. With this, you can specify it instead to be "blur" or "focus" or any other event.

Additionally, you may specify any of the options documented in link_to_remote.

observe_form(form_id, options = {})

Like `observe_field`, but operates on an entire form identified by the DOM ID `form_id`. `options` are the same as `observe_field`, except the default value of the `:with` option evaluates to the serialized (request string) value of the form.

periodically_call_remote(options = {})

Periodically calls the specified url (`options[:url]`) every `options[:frequency]` seconds (default is 10). Usually used to update a specified div (`options[:update]`) with the results of the remote call. The options for specifying the target with :url and defining callbacks is the same as link_to_remote.

remote_form_for(object_name, *args, &proc)

Works like form_remote_tag, but uses form_for semantics.

remote_function(options)

Returns the JavaScript needed for a remote function. Takes the same arguments as link_to_remote.

Example:

      <select id="options" onchange="<%= remote_function(:update => "options",
          :url => { :action => :update_options }) %>">
        <option value="0">Hello</option>
        <option value="1">World</option>
      </select>

submit_to_remote(name, value, options = {})

Returns a button input tag that will submit form using XMLHttpRequest in the background instead of regular reloading POST arrangement. `options` argument is the same as in `form_remote_tag`.

update_element_function(element_id, options = {}, &block)

Returns a JavaScript function (or expression) that‘ll update a DOM element according to the options passed.

- `:content`: The content to use for updating. Can be left out if using block, see example.
- `:action`: Valid options are :update (assumed by default), :empty, :remove
- `:position` If the :action is :update, you can optionally specify one of the following positions: :before, :top, :bottom, :after.

Examples:

      <%= javascript_tag(update_element_function("products",
        :position => :bottom, :content => "<p>New product!</p>")) %>

      <% replacement_function = update_element_function("products") do %>
        <p>Product 1</p>
        <p>Product 2</p>
      <% end %>
      <%= javascript_tag(replacement_function) %>

This method can also be used in combination with remote method call where the result is evaluated afterwards to cause multiple updates on a page. Example:

      # Calling view
      <%= form_remote_tag :url => { :action => "buy" },
        :complete => evaluate_remote_response %>
      all the inputs here...

      # Controller action
      def buy
        @product = Product.find(1)
      end

      # Returning view
      <%= update_element_function(
            "cart", :action => :update, :position => :bottom,
            :content => "<p>New Product: #{@product.name}</p>")) %>
      <% update_element_function("status", :binding => binding) do %>
        You've bought a new product!
      <% end %>

Notice how the second call doesn‘t need to be in an ERb output block since it uses a block and passes in the binding to render directly. This trick will however only work in ERb (not Builder or other template forms).

See also JavaScriptGenerator and update_page.

update_page(&block)

Yields a JavaScriptGenerator and returns the generated JavaScript code. Use this to update multiple elements on a page in an Ajax response. See JavaScriptGenerator for more information.

update_page_tag(&block)

Works like update_page but wraps the generated JavaScript in a <script> tag. Use this to include generated JavaScript in an ERb template. See JavaScriptGenerator for more information.

### Protected Instance methods

build_callbacks(options)
build_observer(klass, name, options = {})
method_option_to_s(method)
options_for_ajax(options)

[Validate]