Ferreteria/v2/usage/forms: Difference between revisions
< Ferreteria | v2 | usage
Jump to navigation
Jump to search
(classes from forms.php) |
(the other file's classes; better layout) |
||
| Line 11: | Line 11: | ||
==Pages== | ==Pages== | ||
* {{l/ferreteria/|changes/1}}: change to Save() parameters | * {{l/ferreteria/|changes/1}}: change to Save() parameters | ||
{| width=100% | |||
| valign=top bgcolor=#efe | | |||
==Files== | ==Files== | ||
* {{ferreteria/code|util/forms.php}} | * {{ferreteria/code|util/forms.php}} | ||
| Line 30: | Line 31: | ||
**** '''clsCtrlHTML_Rating''' | **** '''clsCtrlHTML_Rating''' | ||
* {{ferreteria/code|form-data.php}} | * {{ferreteria/code|form-data.php}} | ||
** {{faint|'''clsCtrls'''}} | |||
*** '''clsForm_recs''' | |||
**** '''clsForm_recs_indexed''' | |||
| valign=top bgcolor=#eef | | |||
==Classes== | ==Classes== | ||
The way this is organized is a little messed up; the descendants of clsCtrls handle database interaction -- but shouldn't it be the descendants of clsFields? It works reasonably well as is, but some rethinking might be a good idea, once everything is all mapped out. | The way this is organized is a little messed up; the descendants of clsCtrls handle database interaction -- but shouldn't it be the descendants of clsFields? It works reasonably well as is, but some rethinking might be a good idea, once everything is all mapped out. | ||
===collections=== | ===collections=== | ||
* '''clsCtrls''' (abstract): a collection of '''clsCtrl''' form controls -- often referred to in code as a "form object" | * '''clsCtrls''' (abstract): a collection of '''clsCtrl''' form controls -- often referred to in code as a "form object" | ||
| Line 38: | Line 42: | ||
*** '''clsForm_recs_indexed''': form object that knows how to interact with a ''keyed'' database table (allowing for additional functionality) | *** '''clsForm_recs_indexed''': form object that knows how to interact with a ''keyed'' database table (allowing for additional functionality) | ||
* '''clsFields''': a collection of '''clsField''' objects | * '''clsFields''': a collection of '''clsField''' objects | ||
===unitary objects=== | ===unitary objects=== | ||
* '''clsField''': a generic (unspecialized) field, suitable for plain text | * '''clsField''': a generic (unspecialized) field, suitable for plain text | ||
| Line 55: | Line 58: | ||
*** '''clsCtrlHTML_ReadOnly''': HTML control for non-editable data | *** '''clsCtrlHTML_ReadOnly''': HTML control for non-editable data | ||
*** '''clsCtrlHTML_Rating''': HTML control for entering a rating (integer with fixed range and intervals) | *** '''clsCtrlHTML_Rating''': HTML control for entering a rating (integer with fixed range and intervals) | ||
|} | |||
Revision as of 21:28, 29 March 2015
About
Forms in Ferreteria consist of several sets of classes that work together:
- control classes render editable (and eventually non-editable) data fields
- field classes handle translating values between internal storage and on-disk storage (database)
Rules
- Every control (clsCtrl) belongs to a control row (clsCtrls).
- Control rows can be indexed in order to allow for multi-row editing.
- clsCtrls should eventually be renamed clsCtrlRow.
- I haven't decided if there needs to be a clsForm class for containing multiple control rows.
- Indexing is optional if you're only editing one row at a time.
Pages
- changes/1: change to Save() parameters
Files
|
ClassesThe way this is organized is a little messed up; the descendants of clsCtrls handle database interaction -- but shouldn't it be the descendants of clsFields? It works reasonably well as is, but some rethinking might be a good idea, once everything is all mapped out. collections
unitary objects
|