Front End.

DynField can only be used with object_types defined in the acs_object_types table. DynField takes advantage of the template form builder. Usually a form is created with template form builder - then DynField uses the proc dynfield::append_attributes_to_form to add elements to the form. (It can also create a new form if needed). Then in the template::form is_valid section the proc dynfield::attribute_store -object_type $object_type -object_id $party_id -form_id $form_id adds or updates any extension records for this object-type for this object_id. It won't create a new object (e.g. party or ticket) though if there is none there(probably a good thing!). No program changes are needed to add new DynField attributes to pages.

 

The proc dynfield::append_attributes_to_form is also used in Search pages by setting the search_p flag to true.

The search results are returned using

template::util::list_of_lists_to_array [dynfield::search_query -object_type "ttracker_ticket" \

      -form_id $form_id \

                  -select_part "" \

                  -from_part $from_part \

                  -where_clause ""] query_info

Note that program changes are still needed in Search pages for new object types to build the queries (the FROM and WHERE clauses).

 

The layout manager decides if an element appears in the search page. We can use the page_url parameter in dynfield::append_attributes_to_form to give different layout versions of the same page.

 

DynField storage types: we only use 2: multimap or value. The difference is in whether we need to store more than 1 value for an attribute i.e. whether to use a child table or a column. If multimap is chosen, then we use the dynfield_attr_multi_value table to store the actual values. The storing is done in dynfield::attribute_store proc.

 

Adding a Widget.

Storage Type: right now Multimap values are only available for Category, Multi-select and Checkbox Widgets. Therefore choosing Multi-Select-Mapping-Table causes the program to ignore most Widget values (NB this includes Generic SQL) and can't be used with those widgets.

 

OpenACS Datatype: this corresponds to an Oracle table column datatype (e.g. number(12,2) - this is used when adding a new attribute to create the actual column on the table (and maybe even check constraints etc). Also used in validation. There's some confusion about the "SQL Datatype" field as this seems to do the same thing. The valid values for SQL Datatype include Integer, char(1), date, integer, number(12,2), string, text.

 

Widget options: these are hard-coded into the program. May eventually need a lookup table. Note that Generic SQL creates a pulldown the options of which are the results of a SQL query - it will need a custom parameter with the SQL query (see Parameters below). Also the SQL query must return 2 columns: the first is the ID, the 2nd is a description.

 

Parameters: this can take 2 things: 1 - the parameters that template::element::create takes. 2 - a special custom parameter that dynfield widgets can take. (We think the valid values for Parameters is limited to just html, options and custom.) Custom contains information that will be used in the relevant template::widget::whatever proc (e.g. template::widget:category_tree for Category etc).

 

Layouts.

If no default layout page specified in the layout manager for an object then any page calling dynfield::append_attributes_to_form will display ALL the dynfield attributes. In general, if there is a layout page with associated attributes, only those associated attributes will be displayed if that layout page is specified (maybe through being the Default or through the page_url parameter to dynfield::append_attributes_to_form etc). Otherwise all attributes are displayed. Toni thinks that Relative isn't fully working - you can only specify one column.

Layout_type: absolute, relative or adp. Ask Banjo.

 

Documentation.

Some in packages/intranet-dynfield/doc. Some in G:\quest\products\AIMS\doc\dynfield.

Toni says the following in the docs may not be true:

In the -on_submit block you enter the following:

 

ad_from ... -on_submit {

        dynfield::ad_form::save \

            -package_key "contacts" \

            -object_type "ct_contact" \

            -list_name "contact_person" \

            -form_name "contact_person_ae" \

            -object_id $ct_contact_id

    }

 

See organisation.tcl for an example of how we do this in practice. We don't use ad_form - instead we use the form builder.

 

 

Code.

All in packages/intranet-dynfield. Toni tells me that the majority of procs aren't actually used (especially the cached/flushed stuff). DynField is based on Matthew Gedderts OpenACS AMS package and can be considered a subset of his work. Therefore many parts of the package are unused/untested by Quest.

 

Notes.

dynfield/attribute-new should give a warning to stop people changing the Widget once the attribute is created.