Index options

Index has three standard actions which can be defined as actions: standard (we will learn more about this in the future). These actions are:

- new (Add new empty record)

- sort (Sort records by field)

- filter (Filter records by value in the specified field)

 

Sort and filter can be optionally controlled by sort and filter options.

 

sort: optional

By default, all dialogs can be sorted by fields which are defined in result_set. They can be sorted by clicking on the header name of the column. If you want to allow sort by any other field, field name must be specified in sort option. If you want to define more than one field, they must be separated by comma.

 

Example:

index:
  sort: email, country, birthdate

 

filter: optional

Similar to sort option, filter option defines fields by which records can be filtered. Filter dialog contains selectable field name, options for equal or like, and field for entering filter data. If more than a single field is defined, they must be separated by comma.

 

DRG CMS searches for definition of the input field in form option. If a definition is found, the data entry field will be presented the same as when edited. Select entry fields will be entered as select_field. Date type fields will be entered as date HTML fields. But not all fields can be filtered as defined on edit form. Fields entered as textarea would look strange on filter dialog if presented as textarea. In order to avoid this problem, field can be defined with additional as field type keyword.

 

Example:

index:
  filter: subject, sub_subject as text_field, author_name, body as text_field

 

actions: optional

There are three standard actions which can be used on a dialog. New, sort and filter. If this will be the only actions on the dialog then they can be specified as:

 

index:
  actions: standard

 

When you want to use only selected standard action, they can be defined like this:

 

index:
  actions:
    1: new
    2: sort

 

or perhaps longer version with some html sugar added.

 

index:
  actions:
    1:
      type: new
      title: Add new empty record
    2:
      type: sort

 

How about when you want to create your own actions. Here is where option type starts to make sense.

 

index:
  actions:
    1:
      type: link
      url: /some_url
      caption: my_locale.link_caption
      title: Will be written on mouse over
      icon: heart
    2:
      type: link
      caption: Link's caption
      controller: cmsedit
      action: index
      table: mytable
      formname: mytable
      title: Edit my table
    3:
      type: menu
      caption: Menu caption
      eval: MyModel.get_menu_method(self)
 

 

Type link creates an action link. The simplest option is URL option, which defines a direct URL to link to. If you want to link to other site, put http:// in front of URL.

 

Link action can of course be more complex. It contains same logic as ROR link_to helper (controller, action). Table and form name parameters will also be included in the resulting link. Thus, link may become any ROR controller/action combination. But be aware that route must be defined in routes.rb otherwise Rails will throw a runtime error when creating action.

Type menu can be used to create dynamic submenu at runtime. Menu assumes that menu code will be returned by a method, which will be evaluated at runtime. Returned code may look like this:

 

Class MyModel

method self.get_menu_options(parent)
  params = {}
  params['controller'] = 'cmsedit'
  params['action']     = 'new'
  params['table']      = 'my_table'
  params['formname']   = 'my_table_form'
  url = parent.url_for(params)
  html = <<EOT
<ul>
  <li>#{parent.link_to('Link caption', params, title: 'locale.some.title')</li>
  <li class="dc-link-ajax dc-animate" id="dc-submit-ajax" 
      data-url="#{url}" data-request="get">Same as ajax link</li>
</ul>
EOT 
end

end


Here we have MyModel class which implements class get_menu_options. self parameter which was used in form becomes parent in called method and represents rails environment object. Thus, we are able to access session (parent.session), params (parent.params) or any Ruby on Rails method, that can be called from ROR herlper.

 

 


Last update: 26.01.2022