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:
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:
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:
actions: standard
When you want to use only selected standard action, they can be defined like this:
actions:
1: new
2: sort
or perhaps longer version with some html sugar added.
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.
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.