
This file outlines some of the logic of bond and how name resolving is
handled.


Fields

Widget names must match a specific field in the database.  Though
expressions like tablename.fieldname are valid though slightly
slower to process.

Any references to a field not present in the current table will
result in a search of directly related tables for that field.

A view can be an additional datasource in a form, so you can have
a widget called viewname.field1 (refers to field1) or just viewname 
(refers to first field in field list for that view).

Views will clarify information on dropdown boxes.  A view of the
same name as a drop down box will be work out what fields are showen
in the dropdown box well the relationship information decleared in
constrants will be the basis of how the record is saved back

A expression of fielda.fieldb will be regarded as constraint
already set up and the desired value to show is fieldb based on the
critera defined in the fielda.fieldb constrant present in the database.

A field directly refercing a field in a view is non-updatable unless
it has the valid sql triggers set up in the database to handle 
modifications of views.


Example of valid expressions for a dropdown box of rank, which
should all generate the same result.

rank_id x
rank.name x
rank_id.name x
rank_idv (a view called rank_idv) x
rank_idv.name (a view called rank_idv) x

rank_id:rank.name

