ictable_editor.sdf

!init OPT_LOOK="icdevgroup"; OPT_STYLE="manual"
# $Id: ictable_editor.sdf,v 1.9 2004-12-29 16:10:37 jon Exp $
!define DOC_NAME "Configuration Reference"
!define DOC_TYPE ""
!define DOC_CODE "icconfig"
!define DOC_VERSION substr('$Revision: 1.9 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://www.icdevgroup.org/doc/ictable_editor.html"
!build_title

H1: Interchange Table Editor

Interchange has a powerful, highly-configurable table editor application
implemented via its C<[table-editor] ...> tag.

It is called in an Interchange page as simply as:

!block example
    [table-editor cgi=1]
!endblock

Given that call, it reads the passed CGI query information and builds a
table editor for an interchange table.

Each field within the table editor is completely configurable for HTML
widget type, label, help links, and more. These configurations can be
saved in the C<mv_metadata> database, or can be specified in the table-editor
tag call itself.

The table editor is portable. It will work with any DBI/SQL database, with
LDAP databases, and with Interchange DBM and plain-file databases.

Much of the Interchange administrative user interface (UI) is built
around the table editor.

Its features include:

LI1: Complete range of widgets and data filters

Interchange has 18 different HTML widget types with data filters to
condition the data.

LI1: Link fields from any table

Though the table editor uses one table as its base, fields from other
tables can be brought in, and entire sets of records relationally linked
to the base record can be edited within the table editor.

LI1: Tabbed display

Interchange automatically builds a tabbed interface from your
fields specification.

LI1: "Wizard" mode

The table editor has a "wizard" mode that can collect information for
accomplishing installation or setup tasks, with Next, Back, Cancel
and Finish modes.

LI1: Templatable setup 

You can completely control the way the table editor displays
the widgets without interfering with its functionality.

LI1: Complex data structures

Interchange can build arbitrarily-deep data structures from
form input. The collected data is serialized with the equivalent
of Perl's Data::Dumper and stored in a single database field.

H2: Calling the table editor

In its simplest form, table-editor is called in an ITL page with:

!block example
    [table-editor table=products key=os28004][/table-editor]
!endblock

That will edit the table products using its default configuration,
for the SKU C<os28004>. 

If no metadata is defined for the table, all fields are edited.
To limit it with the tag call:

!block example
    [table-editor
        table=products
        key=os28004 
        fields="sku price description" ][/table-editor]
!endblock

To specify that the field description should have a different
widget type, height, and width, you can specify:

!block example
    [table-editor
        table=products
        key=os28004 
        fields="sku price description"
        widget.description=textarea
        width.description=50
        height.description=10
    ][/table-editor]
!endblock

If you do this with the default C<foundation> demo catalog, you will see:

!block example
   SKU            __________________________________

   Product Price  __________

                  +---------------------------------------------+
                  |                                             |
   Short          |                                             |
   Description    |                                             |
                  |                                             |
                  +---------------------------------------------+
!endblock

Note that the labels are pulled from the C<mv_metadata> definition -- any
attributes not specified in the options do that. You can override each
in turn -- to change SKU to "Part Number" you can do:

!block example
    [table-editor
        table=products
        key=os28004 
        fields="sku price description"

        label.sku="Part number"

        widget.description=textarea
        width.description=50
        height.description=10
    ][/table-editor]
!endblock

To change the style of the label column, you can set the style
information with:

!block example
    [table-editor
        table=products
        key=os28004 
        fields="sku price description"

        label_cell_style="font-weight: bold"

        label.sku="Part number"
        widget.description=textarea
        width.description=50
        height.description=10
    ][/table-editor]
!endblock
    
This should B<bold> the label text.

These are just a few small examples. There are more than 150 options
for table editor which we will discuss below.

H2: Attributes and attribute quoting

The [table-editor] is capable of accepting a large number of attributes.
It uses standard ITL tag quoting, explained in
the {{CMD[jump="ictags.html#Tag Syntax"]Interchange Tag Reference}}.

You can quote with single-quote (<'>), double-quote (C<">), backtick (C<`>),
or pipe (C<|>). Material placed in backticks is run through a safe
Perl interpreter. In fact, it is the equivalent of using
the [calc] [/calc] tag pair except that contained ITL tags are not
interpolated.

Pipe-quoting has the attribute of stripping trailing and leading
whitespace; it is often convenient when specifying JavaScript (which uses
both single and double quotes frequently) in the various C<*_extra> parameters.

H2: Templating

The [table-editor] is templated on several levels. In the most basic
use, where you rely on it to build the table rows, there is the
row_template option. By default, $row_template is:

!block example
   <td$opt->{label_cell_extra}> 
     {BLABEL}{LABEL}{ELABEL}{META_STRING}
   </td>
   <td$opt->{data_cell_extra}>
     <table cellspacing=0 cellmargin=0 width="100%">
       <tr> 
         <td$opt->{widget_cell_extra}>
           {WIDGET}
         </td>
         <td$opt->{help_cell_extra}>
            {TKEY}
            {HELP?}<i>{HELP}</i>{/HELP?}
            {HELP_URL?}<BR><A HREF="{HELP_URL}">help</A>{/HELP_URL?}
         </td>
       </tr>
     </table>
   </td>
!endblock

When using the row_template option, the $opt->{foo} hash references are trapped by 
Safe. These values need to be translated into ~OPT:foo~ and are automatically converted.

~FOO_EXTRA~ will be expanded into $opt->{foo_extra} if $opt->{foo_extra} is defined, 
otherwise, it expands into $opt->{foo_cell_extra}.
 
The values of $opt->{*_cell_extra} are constructed from the *_cell_class,
*_cell_width, *_cell_valign, *_cell_align, *_cell_style, and *_cell_extra
options. You can watch the effect by trying different settings:

!block example
  [table-editor
            table=products
            key=os28004
            label_cell_class=myclass
            label_cell_width=10%
            label_cell_valign=top
            label_cell_extra=|bgcolor="cyan"|
            ][/table-editor]
!endblock

The values specified with {LABEL}, {WIDGET}, etc. are what are used
to substitute the widget values constructed from the metadata. A perfectly
functional template would be:

  <td>{LABEL}</td><td>{WIDGET}</td>

That would show the label and widget without any help being shown (even
if it is available) and using the default styles for at table data cell.

There is also the overall template, which is passed as the container
text for [table-editor]. Something equivalent to the default can be
achieved with:

    {TOP_OF_FORM}
    {HIDDEN_FIELDS}
    <table>
        <tr>
            <td>&nbsp;</td>
            <td>{TOP_BUTTONS}</td>
        </tr>
        {:REST}
        <tr>
            <td>&nbsp;</td>
            <td>{BOTTOM_BUTTONS}</td>
        </tr>
    </table>
    {BOTTOM_OF_FORM}

There are two other templates -- the break_template and the
combo_template. See "Templates".

H2: Metadata

Interchange's foundation demonstration catalog and UI rely on
a table named C<mv_metadata>, which contains the definitions for
table and field appearance. This table is supported with a
table definition editor (pages/admin/db_metaconfig) and a field
definition editor (pages/admin/meta_editor).

The C<mv_metadata> table has the following fields:

LI1: code

The key for the table. Normally, it takes the form

!block example
    table::column
!endblock

where table is the table the field is contained in, and column
is the table column name. It can also take the forms:

!block example
    view::table::column::key
    view::table::column
    table::column::key
!endblock

Each is checked in turn to see if it exists, then applied. If
none of the above is found, then the field is displayed with
a default widget (a text box with size 50).

LI1: type

The widget type. The following, at least, are supported:

!block table
Type|Name|Description
text|Text entry|The normal HTML text entry field.
textarea|Textarea|The normal HTML textarea entry for putting in multiple lines of data.
select|Select box|Also known as as a dropdown menu. Interchange has many ways to populate the options via automatic database lookup, and you can specify options to add or replace a lookup.
yesno|Yes/No (Yes=1)|A dropdown/select looking for a Yes (1) or No (0) answer.
noyes|No/Yes (No=1)|A dropdown/select looking for a Yes (0) or No (1) answer.
yesno radio|Yes/No (radio)|Same as the yesno widget except implmented with a radio box.
noyes radio|No/Yes (radio)|Same as the noyes widget except implmented with a radio box.
multiple|Multiple Select|A dropdown/select with SIZE greater than 1.
combo|Combo Select|A dropdown/select with a preceding text entry field that can add a new entry. Needs the C<nullselect> filter; usually combined with a lookup.
reverse_combo|Reverse Combo|A dropdown/select with a following text entry field that can add a new entry. Needs the C<last_non_null> filter; usually combined with a lookup.
move_combo|Combo move|A dropdown select that sends clicked items to a textarea.
display|Text of option|Displays the label (only) for a select/radio choice.
hidden_text|Hidden (show text)|Shows the value of a field and includes a hidden field to put the value in the form. Usually used when you want to display a key for a record but not give the opportunity to change it (and create a new record).
radio|Radio box|Select one of many options with a check box. Usually can be used instead of a select; can be grouped in matrices.
radio_nbsp|Radio (nbsp)| Select one of many options with a check box. Usually can be used instead of a select; can be grouped in matrices. This version puts no spaces in the outputted HTML, guaranteeing no wrap. (You can use the newer nowrap styles in CSS instead, often.)
checkbox|Checkbox|Select one or more options with a checkbox. Usually can be used instead of a multiple select.
check_nbsp|Checkbox (nbsp)|Select one or more options with a checkbox. Usually can be used instead of a multiple select. This version puts no spaces in the outputted HTML, guaranteeing no wrap. (You can use the newer nowrap styles in CSS instead, often.)
imagedir|Image listing|Shows a list of already existing images in a directory, with a link to a dialog to upload a new one.
imagehelper|Image upload|Combines input of an image name along with upload of the image.
date|Date selector|Selects a date, with optional time. Used in combination with the C<date_change> filter.
value|Value|Simply shows the value of the field, with no widget to set it.
option_format|Option formatter
show|Show all options|Shows all options for a select/radio/checbox type input, without a widget to set the value.
uploadhelper|File Uppload|Puts the contents of a file upload in the named variable. Can be used as filter.widget="upload"
!endblock

These widgets are implemented with the Vend::Form module, and are
discussed in more detail later in this document.

LI1: width

The width of the widget. Meaningful in some way for most types.

LI1: height

In the field metadata, it is meaningful for textarea, multiple select
types (including the combo widgets), and for groups of radio and checkboxes.

In the table metadata context, defines the number of rows that will
be shown on the record select page before a "more" list will be built.

LI1: field

The fields for an options lookup query if more than one. Default is
none -- the field in "lookup" is used.

LI1: db

The table to do the lookup query in. Default is the same table
as the column is in.

LI1: name

The name of the generated HTML form element. Default is the same
name as the column for the widget.

LI1: outboard

Catchall field used in several ways by different widgets. Normally
used to specify a foreign key, it can also contain a directory name
or other information needed for a widget.

LI1: options

Hard-coded options for the select, checkbox, and radio box widget
types.

LI1: attribute

Not normally used for table editor. Used in Interchange in the context
of an [item-list ...] for generating option names.

LI1: label

The label associated with the field for display in the table editor.
In the below example, "Foo" is the label:

!block example
    Foo: <input type=text value="bar" size=30>
!endblock

LI1: help

Inline help to be displayed in the table editor.

LI1: lookup

A field name to look up options in. Normally this would be the same
field as the widget, to generate a list of unique values. The equivalent
to the query:

!block example
  SELECT DISTINCT foo FROM table ORDER BY foo
!endblock

is done.

LI1: filter

A filter which should be applied to the data coming from a widget
before saving in the database. A few examples of the dozens of
standard filters are:

LI2: nullselect

.Select first non-null from HTML fields, used for combo box widget

LI2: digits_dot

.Helps keep currency symbols and punctuation from polluting decimal values.

LI2: uc

.Uppercases the data.

LI2: NN

.Where NN is an integer. A number that limits length of input.

There are many more filters, and it is easy to specify custom
filters. See Interchange's filters documentation.

LI1: help_url

A URL for extended help on a field.

LI1: pre_filter

For advanced use only. Specifies a filter that is run on the data before
it is used to set the widget value. Not normally used.

LI1: lookup_exclude

A regular expression that can exclude certain values from a lookup list.

LI1: prepend
LI1: append

Valuse that are prepended and appended to the widget HTML, perhaps to
call an external formatter or tool.

LI1: display_filter

Not normally used.

LI1: default

The default value that should be given to a column when it is of length
zero.

LI1: extended

The repository for the serialized extended values set in metadata.

H2: Extended settings

Interchange's meta editors use the table editor's serialization capability
to set many more than just the fields mentioned above. There are over
150 different metadata settings, and it would be impossible to have each
occupy a field in a table.

Many of these settings can be passed in a CGI query string if
the cgi=1 option is specified.

LI1: across

The number of label-widget pairs which should be placed on each
table row. The default is 1. Not passable by CGI.

LI1: action

The Interchange form action to use for the generated form. In normal
mode, the default is "set". In wizard mode, the default is "return".
Not passable by CGI.

LI1: action_click

An mv_click action that should be run on the Wizard next function.
The default is "ui_override_next", which is usually a no-op on
most systems.  Not passable by CGI.

LI1: all_errors

Specifies that all form field entries should be checked for errors and their
label fields set to the CONTRAST setting if an error is found.

LI1: all_opts

An ITL tag option that specifies that the table-editor options should
be retrieved from one source.

If the option is a HASH reference, it will be used directly as a structure
that will set all options.

If it is a scalar value, it will be used as a key to select the mv_metadata
record which contains the options.

LI1: append

Active for every column in ui_data_fields. A value containing HTML which
should be appended to the widget HTML.

LI1: auto_secure

Instructs Interchange to build a write enable only for the tables, columns,
and keys that are specified in the table-editor call. Note that you can
allow unfettered writes by setting the scratch variable C<mv_data_enable>,
but that it is rarely right to do so.

This prevents people from hacking together a duplicate of the [table-editor]
form and writing columns or records they shouldn't.

This option is automatically disabled if the C<cgi> option is enabled. Still,
you should pay attention to what you are allowing users to write to your
database.

LI1: back_text

The text that should be used in the Wizard B<Back> button. Automatially
translated for locale.

LI1: bottom_buttons

Indicates that buttons should always be only on the bottom.
Normally, C<[table-editor]> provides a top row of buttons if more than four
rows are in the table.

LI1: break_cell_extra

Extra HTML attributes for the table cell in the standard break_row
template. You might pass a valign, align, class, or other attribute:

!block example
    break-cell-extra=|class="myclass"|
!endblock

LI1: break_row_extra

Extra HTML attributes for the table row in the standard break_row
template. You might pass a valign, align, class, or other attribute:

!block example
    break-row-extra=|class="myclass"|
!endblock

LI1: break_template

The HTML template that is used to present a break row. Default is:

!block example
	<tr$opt->{break_row_extra>
		<td colspan=$span $opt->{break_cell_extra>&nbsp;</td>
	</tr>
!endblock

LI1: cancel_button_style

The HTML style for the cancel button.

LI1: cancel_text

The text placed in the "Cancel" button in both editor and wizard mode.
Default is "Cancel".

LI1: cell_span

The number of cells that are in the span of a normal widget-label
pair. The default is two, which is appropriate for the label in one
table cell and the widget in the other. If you have a row_template
like:

!block example
	<td>{LABEL}</td><td> --&gt; </td><td>{WIDGET}</td>
!endblock

you would want a cell_span of three. For the row_template 

!block example
	<td align=left>
		<b>{LABEL}</b><br>
		{WIDGET}
	</td>
!endblock

you would want a cell_span of 1.

This allows the formatter to build the right number of cells for spacers
and whole_row templates.

LI1: cgi

Signifies that some options may come from the URL calling the page where
the C<[table-editor]> resides.

This allows a simple:

!block example
	[table-editor cgi=1][/table-editor]
!endblock

to be active for any table and key that are called with a URL like:

!block example
  http://your.catalog.url/cat/admin/flex_editor?mv_data_table=products?item_id=1
!endblock
	
The C<auto-secure> option is turned off if this option is set, for it would
then be possible for people to call a table and set their own security.

LI1: check

A hash option that is active for every field. Defines a profile check that
should be run on the field before the record will be allowed to be set
(or the wizard allowed to go to the B<Next> option.

This call

!block example
	[table-editor
		table=products
		item_id="[cgi sku]"
		check.description=required
	][/table-editor]
!endblock

ensures that the description field will be non-blank and non-zero
before the record is written.

Works in conjunction with the C<process_filter> profile provided
as a part of the UI. If using the table editor outside the province
of the UI, you will need to make sure you get this profile included;
it normally resides in lib/UI/profiles.

LI1: clear_image

In cases where the table-editor templates need a transparent image for
display padding, can set the path where that image is. Default
is C<bg.gif>, which comes with the Interchange UI.

LI1: color_fail

The color to set failure messages to in HTML. Default Red.

LI1: color_success

The color to set success messages to in HTML. Default Green.

LI1: data_cell_class
LI1: data_cell_style
LI1: data_cell_valign
LI1: data_cell_width
LI1: data_cell_align
LI1: data_cell_extra

The settable parameters allowing change of the HTML appearance of the
data cell in the standard C<[table-editor]> presentation. The 
default is C<data_cell_class> set to I<cdata>.

The easiest thing to do to alter the look is define the CSS class for
I<cdata> how you want it. But you can individually set the width, style,
and alignments; and you can attach scripting events or other CSS calls
to the cell as well with C<data_cell_extra>.

The following table-editor call:

!block example
	[table-editor
		table=products
		item_id="[cgi sku]"
		data_cell_class=newclass
		data_cell_style="color:red"
		data_cell_extra=|onMouseOver="alert('move that mouse!'"|
		data_cell_valign=top
	][/table-editor]
!endblock

will result in a templated row of:

!block example
	<td class=clabel>{LABEL}</td>
	<td class="myclass"
		style="color:red"
		valign="top"
		onMouseOver="alert('move that mouse!')">
			{WIDGET}{HELP?}{HELP} ... (rest of template)
	</td>
!endblock

LI1: database

A hash attribute with a key associated with every field. Specifies the
database table that will be used for a lookup (if any).

LI1: default

A hash attribute with a key associated with every field. Specifies the
default value that will be used in the field if none is found in the
table or otherwise available via the B<default_ref>.

This is only active if the C<defaults> flag is set.

LI1: default_ref

The hash reference that is used to set the defaults for the fields 
if there is no data in the table for that row. Default is $Values,
the Interchange values hash.

You can set this in options with:

!block example
	[table-editor default_ref=`$CGI`]
!endblock

Note the backticks. This calls Perl, which returns the $CGI reference.

If you have previously collected some defaults in a scratch variable,
you could use that with:

!block example
	[table-editor default_ref=`$Scratch->{myhash}`]
!endblock

Not settable in metadata, and it *must* be a hash reference or there
will be a fatal error.

This is only active if the C<defaults> flag is set.

LI1: defaults

Allows defaults to be set from the C<default> hash above. When used in
combination with C<force_defaults=1> forces the passed defaults to
override any data previously residing in the table record.

LI1: enctype

The encoding type for the form generated by [table-editor]. If
the C<file_upload> option is set, it defaults to C<multipart/form-data>,
otherwise uses the form default for the browser (which is 
normally C<application/x-www-form-urlencoded>).

LI1: extra

A hash attribute with a key associated with every field. Specifies some
extra HTML parameter(s) which will be attached to the widget for the
field, based on the behavior of Vend::Form.

Normally used to pass an onChange or other scripting event.

LI1: field

A hash attribute with a key associated with every field. Specifies the
fields to be used as a value-label pair for a lookup (if there is one).
Works in conjunction with the C<lookup> and C<database> tags.

To build a list of products for selection by SKU in the C<foo> widget, without
having to use the SKU as the label, you can do:

!block example
  [table-editor
  	foo.widget=select
  	foo.lookup=1
  	foo.database=products
  	foo.field="sku,description"
  /]
!endblock

Essentiallly the same as:

!block example
  [table-editor
	foo.widget=select
	foo.lookup_query="select sku,description from products order by description"
  /]
!endblock

LI1: file_upload

Specifies that file upload should be enabled by changing the form encoding type.
Forms using the C<imagehelper> widget need this set.

LI1: filter

A hash attribute with a key associated with every field. Specifies a
filter that will be applied to the widget result data before it is put
in the database. To make sure that an integer value doesn't have
extraneous whitespace that could cause an error, do:

!block example
  [table-editor
	foo.widget=text_5
	foo.label="Seconds before we should become impatient and beep"
	foo.filter=digits
  /]
!endblock

Filters can be chained; they are the normal Interchange filters active
in many situations.

Works in conjunction with the C<process_filter> profile provided
as a part of the UI. If using the table editor outside the province
of the UI, you will need to make sure you get this profile included;
it normally resides in lib/UI/profiles.

LI1: force_defaults

Causes the entries in the "defaults" hash to be used to set the initial
value of fields, disabling the preference for data coming from an
existing record in the database.

LI1: form_extra

Extra information (usually scripting event calls) for the form. For instance,
if you are maintaining a series of event monitors in and want to make sure
the user knows that some changes will be lost, you can set up a routine
named C<check_change()> in JavaScript. To check the change and ask for
a confirmation before submission, you can do:

!block example
  <script>
  var changed = new Array;
  function is_changed (element) {
	if(element != undefined)
		changed[changed.length] = element.name;
  }

  function check_change () {
	if(changed.length > 0) 
	  return
	  	confirm('the ' + changed.join(',') + ' elements were changed. Continue?');
	return true;
  }
  </script>

  [table-editor
	foo.widget=text_50
	foo.label="Important stuff"
	foo.extra='onChange="is_changed(this)"
	form_extra='onSubmit="return check_change()"'
  /]
!endblock

You could also pass style information if that is ever appropriate. For
form name, action, and target, 

LI1: form_name

The name of the form. Do not include the C<NAME=> portion, that is provided.
Results in outputted HTML of:

!block example
	<FORM ACTION="$opt->{form_action}" METHOD=POST NAME="$opt->{form_name}">
!endblock

LI1: get

Sets the method for the form to GET -- the default is POST.

LI1: height

A hash attribute with a key associated with every field. Sets the
height of the widget if that is appropriate -- for example, it sets
the ROWS parameter of a TEXTAREA, the SIZE parameter of a SELECT,
etc. Also acts on the combination widgets according to the behavior
of Vend::Form.

If you want to set the height of a cell, you should use the C<*_extra>
parameters.

LI1: help

A hash attribute with a key associated with every field. Specifies inline help
that should be shown in the right-hand (data) portion of a widget row.

LI1: help_anchor

Sets the text that is used to anchor the C<help_url> link. Default is C<help>.
Can also be used to set an image if you want to use that instead:

!block example
  [table-editor
  	table=products
	key=os28004
	help_anchor='<img src="question_mark.jpg" border=0>'
  /]
!endblock

LI1: help_cell_class
LI1: help_cell_style
LI1: help_cell_valign
LI1: help_cell_width
LI1: help_cell_align
LI1: help_cell_extra

Sets the help cell attributes. See B<data_cell_extra>.

LI1: help_url

A URL which leads to extended help on a field. For example:

!block example
  [table-editor
  	table=products
	key=os28004
	widget.foo=text_50
	label.foo="Important stuff"
	help.foo="This is a complex field."
	help_anchor="Search for more help"
	help_url.foo="http://www.google.com/search?q=foo"
  /]
!endblock

LI1: hidden

Allows setting of extra hidden variables in a form. This is a hash attribute,
with one key for every hidden variable you need to set.

!block example
  [table-editor
  	table=products
	key=os28004
	hidden.foo=bar
	hidden.buz=baz
  /]
!endblock

The above will include 

!block example
	<input type="hidden" name="foo" value="bar">
	<input type="hidden" name="buz" value="baz">
!endblock

LI1: href

Sets the action for the form. By default it is {{CMD[jump="icconfig.html#VendURL"]VendURL}}/ui,
which checks for authorization for setting table records. If the C<secure=1>
parameter is set, {{CMD[jump="icconfig.html#SecureURL"]SecureURL}} will be used instead.
parameter is set, the SecureURL
the default 
LI1: include_before
LI1: include_form
LI1: inner_table_width
LI1: item_id
LI1: js_changed
LI1: keep_errors
LI1: label
LI1: label_cell_extra
LI1: label_cell_width
LI1: layer_panel_style
LI1: layer_tab_style
LI1: left_width
LI1: link_before
LI1: link_extra
LI1: link_fields
LI1: link_key
LI1: link_label
LI1: link_sort
LI1: link_table
LI1: link_template
LI1: link_view
LI1: lookup
LI1: lookup_query
LI1: mailto
LI1: message_label
LI1: meta
LI1: meta_anchor
LI1: meta_anchor_specific
LI1: meta_append
LI1: meta_class
LI1: meta_extra
LI1: meta_prepend
LI1: meta_style
LI1: method
LI1: mv_auto_export
LI1: mv_blob_field
LI1: mv_blob_label
LI1: mv_blob_nick
LI1: mv_blob_only
LI1: mv_blob_pointer
LI1: mv_blob_title
LI1: mv_cancelpage

Specifies the destination page if you hit the cancel-button.

LI1: mv_data_auto_number
LI1: mv_data_fields
LI1: mv_data_function
LI1: mv_data_table
LI1: mv_failpage
LI1: mv_nextpage
LI1: mv_prevpage
LI1: next_text

You can customize an alternative text for the OK/Next button.

Note! If your alternative text is long, and you get the text chopped, be
sure to specify a wider button with the ok_button_style setting (eg.
ok_button_style=|font-weight: bold; width: 80px; text-align: center|)

LI1: no_bottom

By default, form buttons are displayed at the top and bottom of the table.
Specifying no_bottom=1 prevents the bottom set of buttons from being displayed.
>     no_bottom=1

LI1: no_meta
LI1: no_table_meta
LI1: no_top

By default, form buttons are displayed at the top and bottom of the table.
Specifying no_top=1 prevents the top set of buttons from being displayed.
>     no_top=1

LI1: nodelete
LI1: noexport
LI1: nosave
LI1: notable
LI1: ok_button_style
LI1: options
LI1: orig_back_text
LI1: orig_cancel_text
LI1: outboard
LI1: override
LI1: panel_append
LI1: panel_height

Specifies the height of the data panels used in the tabbed diaplay.
The default is 600.
>    panel_height=600

LI1: panel_id

Specifies the prefix used to identify the panels used in the tabbed display.
The default is mvpan.
>    panel_id=mvpan

LI1: panel_prepend
LI1: panel_style

Specifies the CSS style applied to the data panels used in the tabbed display.
The default is:
>    font-family: sans-serif;
>    font-size: smaller;
>    padding: 0;
>    border: 2px;
>    border-color:#999999;
>    border-style:outset;

LI1: panel_width

Specifies the width of the data panels used in the tabbed display.
The default is 800.
>    panel_width=800

LI1: passed
LI1: pre_filter
LI1: prepend
LI1: promiscuous
LI1: reload
LI1: reparse
LI1: restrict_allow
LI1: row_template

Allows the use of a user-defined row_template.  

The default is:

!block example
   row_template='
   <td ~OPT:label_cell_extra~>
     {BLABEL}{LABEL}{ELABEL}{META_STRING}
   </td>
   <td ~OPT:data_cell_extra~>
     <table cellspacing=0 cellmargin=0 width="100%">
       <tr>
         <td ~OPT:widget_cell_extra~>
           {WIDGET}
         </td>
         <td ~OPT:help_cell_extra~>
            {TKEY}
            {HELP?}<i>{HELP}</i>{/HELP?}
            {HELP_URL?}<BR><A HREF="{HELP_URL}">help</A>{/HELP_URL?}
         </td>
       </tr>
     </table>
   </td>'
!endblock

LI1: save_meta
LI1: secure
LI1: show_reset
LI1: simple_row
LI1: start_at
LI1: start_at_index
LI1: tab_bgcolor_template

Controls the iteration over the range of bgcolor attributes of the tabs in the 
tabbed display. If tab_bgcolor_template="#xx0000" the tabs will be set to 
"#ff0000" "#ee0000", etc. The default is "#xxxxxx" and the values are set to 
"#ffffff" "#eeeeee",etc. This option allows one to specify a range of colored tabs. 
>    tab_bgcolor_template="#xx0000" 

LI1: tab_height

Specifies the height of the tabs in the tabbed display. The default is 20px.
>    tab_height=20

LI1: tab_horiz_offset

Specifies the number of pixels that additional rows of tabs are shifted to the right.
The default is 10px.
>    tab_horiz_offset=10

LI1: tab_style

Specifies the CSS style applied to the tabs in the tabbed display.
The default is:
>   text-align:center;
>   font-family: sans-serif;
>   line-height:150%;
>   font-size: smaller;
>   border:2px;
>   border-color:#999999;
>   border-style:outset;
>   border-bottom-style:none;

LI1: tab_vert_offset

Specifies the number of pixels that additional rows of tabs are shifted upward.
The default is 20px.
>    tab_vert_offset=20

LI1: tab_width

Specifies the width of the tabs in the tabbed display. The default is 120px.
>    tab_width=120

LI1: tabbed

This option specifies that the tabbed display mode is to be used.  The tabbed=1 option 
displays sections as DHTML tabbed panels.

LI1: table

This option specifies the table as the source / destination of the form fields.  
The table is specified in the form: table=products.

LI1: table_width
LI1: td_extra
LI1: template
LI1: ui_blob_hidden
LI1: ui_blob_widget
LI1: ui_break_before
LI1: ui_break_before_label
LI1: ui_clone_id
LI1: ui_clone_tables
LI1: ui_data_fields

Specifies the database fields that a form collects. This is a quoted space 
delimited list of column names from the database table.

>     ui_data_fields="field1 field2 field3"

LI1: ui_data_fields_all
LI1: ui_data_key_name
LI1: ui_display_only

A quoted space delimited list of fields to be displayed but not edited.
>    ui_display_only="property_id"

LI1: ui_hide_key

Hides the key-field in the form. Remember that if you use the B<fields>
option, then you have to include the key-column in that
list. Otherwise the form will fail to update the record.

LI1: ui_meta_specific
LI1: ui_meta_view
LI1: ui_new_item
LI1: ui_profile
LI1: ui_profile_success
LI1: ui_wizard_fields

Specifies the fields that a form collects in wizard mode.
>     ui_wizard_fields="wiz_field1 wiz_field2 wiz_field3"

LI1: widget
LI1: widget_cell_extra
LI1: widgets_only
LI1: width
LI1: wizard

Specifies that the form collects data as session variables as 
opposed to database fields. Data fields are specified using 
the B<ui_wizard_fields> option.

LI1: wizard_cancel
LI1: wizard_next

Line:

N:Copyright 2002-2004 Interchange Development Group. Freely redistributable
under terms of the GNU General Public License.