RapidApp::Manual::TableSpec - RapidApp/DBIC metadata config options
TableSpecs are RapidApp-specific metadata associated with DBIx::Class Result Classes which affect the behavior of automatically generated interfaces, interacting with the given source, throughout the RapidApp application.
TableSpecs also provide additional Row methods to Result Classes when loaded.
TableSpecs can be loaded via load_components, however loading is handled atomatically by higher-level APIs, namely RapidDbic. See RapidApp::Manual::RapidDbic for where and how to supply TableSpec params.
Friendly title associated with the source in single row context (i.e. singular). This is a label common to all the rows in the source. This is very often the same as the source name (the default), such as 'Album', but could be more verbose, such as 'Music Album'.
Friendly title associated with the source in multiple row, or set context (i.e. plural). This might be 'Albums' or 'Music Albums' for the source 'Album'. This is used when showing lists of rows from the given source.
Defaults to 'SOURCE_NAME Rows' (i.e. 'Album Rows').
Icon associated with the source in single row context (i.e. singular). This should be a CSS class name in the same format as 'iconCls' in ExtJS. This is typically something like icon-apple where the associated class defines a background image. Expects a 16x16 icon.
This icon is displayed in various single-row contexts, such as in tab titles (for row pages) or inline in various places.
See RapidApp::Manual::Assets for information on setup of icon assets and icon CSS classes in RapidApp.
Defaults to 'ra-icon-pg'
Icon associated with the source in multiple row, or set context (i.e. plural). This should be a CSS class name in the same format as 'iconCls' in ExtJS. This is typically something like icon-apples where the associated class defines a background image. Expects a 16x16 icon.
Defaults to 'ra-icon-pg-multi'
Column used when displaying an individual row. Used when this source is the target of a single relationship (i.e. belongs_to)
Defaults to the first primary key column, or the first column if there are no primary keys.
Default editor interface to use when selecting a row from this source (i.e. setting/changing a single relationship, or belongs_to). Current supported values are grid, combo, dropdown and custom.
In RapidDbic this is set to custom with an automatic config that attaches to the default grid for the source. This is effectively the same as grid but without configuring a separate RapidApp module.
combo and dropdown set up a dropdown box with the items listed showing the value of the display_column for each row. combo also enables type-in search/filtering of the list (which triggers a LIKE query on the display_column) while dropdown does not. combo is a nice alternative to grid when there is a limited number of rows to select from and/or if text searching on the display_column alone is sufficient to distinguish them between them. dropdown is only suitable when both are the case, but is more than sufficient and optimal when it is (i.e. for things like a 'status' table with just a handful of static rows).
grid is by far the most powerful choice, but the tradeoff is that it is much slower to interact with since it loads an entire grid interface in a pop-up window, instead of quick little inline combo/dropdown box. But, this mode has all the same capabilities as any other grid, including not only the query tools like quick search and filters, but also the ability to select a row that doesn't already exist by adding it on-the-spot, which is not available in the other types.
Since the system doesn't have a reliable way of determining that combo/dropdown would be sufficient for a given source, the default is grid which is the safest choice to ensure all needed options are available -- it is better to have them and not need them than need them and not have them.
HashRef of column names to TableSpec column configs. See COLUMN CONFIG PARAMS below.
These config settings apply to individual columns within the source. Most of the config options from Ext.grid.Column are supported here with some additional custom behaviors. Many of these options are automatically configured based on the column type from the schema.
Friendly name associated with the given column. Used in labels such as grid column headers.
Defaults to the column name.
Default size in pixels. Default value based on the column type and length.
Boolean. Defines whether or not the column will be sortable in contexts such as grids. Defaults to true.
Boolean. Hides the column from being shown/selected as a column in grid views. Does not affect other contexts, such as Quick Search and MultiFilters (see no_quick_search/no_multifilter options). Defaults to false.
Boolean. Excludes the column from the Quick Search in grids. Defaults to false.
Boolean. Excludes the column from the MultiFilter Search in grids (Filter button). Defaults to false.
Boolean. Excludes the column from column summaries in grids. Defaults to false.
Boolean. Forces queries from the Quick Search to only use exact mode ('=' instead of LIKE %string% sub-string match) for the given column, regardless of the client-side Quick Search mode. This is already implied for numeric columns since it would never make sense to attempt to match them against a sub-string.
Boolean. Determines if an individual column is allowed to be used when adding new rows. This setting is not relevant when the column is not already included by the creatable_colspec. Defaults to true.
Boolean. Determines if an individual column is allowed to be changed when editing a row. This setting is not relevant when the column is not already included by the updatable_colspec, or when there is no editor defined. Defaults to true.
Boolean. Same as no_column setting (but inversed), but for page context (i.e. single row) instead of grid/multi context. Defaults to false when no_column is set, but true when allow_edit is set. Different combinations of the 3 can be used to accomplish various scenarios. For example, these settings will hide a column from grids but show it on the row page read-only:
no_column => 1,
allow_edit => 0,
allow_view => 1
HashRef config of an ExtJS Field/Component. This is automatically setup based on column type, nullability, auto_editor_type for relationship columns, etc, but can be overridden here. If this is set to a false or empty value it will disable editing for the column across the board.
Again, this is automatically configured based on the column type info.
Optional HashRef of config options to be merged into the config of the auto-generated editor for relationship columns. The kind of auto-generated editor depends on the value of auto_editor_type in the TableSpec config of the remote source.
Only applies to single relationship columns - for expert/advanced usage only.
Optional sprintf format to apply to the operator used to query the column in quick search and MultiFilters. This feature has been added specifically to support Type Casting in PostgreSQL.
For instance, special column types need to be "cast" in order for text/string queries to work:
search_operator_strf => '::varchar %s'
The above setting will prefix the raw SQL operator used when querying the column with ::varchar. For example, this would change a WHEREclause that would normally be generated like this:
WHERE column LIKE 'foo%'
to be generated like this:
WHERE column ::varchar LIKE 'foo%'
ArrayRef list of column profile names. Column profiles are macros/sets of column configs to apply multiple options at once. Many of these are automatically set according to the column type.
Column profiles are defined in RapidApp::TableSpec::Column::Profile.
Currently available column profiles:
To install RapidApp, copy and paste the appropriate command in to your terminal.
perl -MCPAN -e shell
For more information on module installation, please visit the detailed CPAN module installation guide.