Ferreteria/v0.5/feature: Difference between revisions
< Ferreteria | v0.5
Jump to navigation
Jump to search
m (7 revisions imported: moving this project here) |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{fmt/title|the Features system}} | |||
A "Feature", in this context, is a set of classes which work together to handle a particular type of data, traditionally represented by a table in a database. The class-set for each Feature is primarily organized around a descendent (subclass) of the Feature class. | A "Feature", in this context, is a set of classes which work together to handle a particular type of data, traditionally represented by a table in a database. The class-set for each Feature is primarily organized around a descendent (subclass) of the Feature class. | ||
Each Feature subclass represents a singleton object and has a SpecSlug() static method for identifying its table specs in the config data. | Each Feature subclass represents a singleton object and has a SpecSlug() static method for identifying its table specs in the config data. | ||
===Related | ==Pages== | ||
* {{l/ver|registry/feature|feature registry}} | * [[/rendering]]: how Feature data is converted to display output (typically HTML) | ||
== | * [[/access]]: how to access a Feature object | ||
==Related== | |||
* {{l/ver|registry/feature|feature registry}}: translates URI slugs into Feature objects | |||
* {{l/ver|registry/table|table registry}}: allows cross-referencing of tables within an app | |||
==Connections== | |||
A Feature that uses a Table doesn't know directly about that Table. The way the Table is accessed goes like this: | |||
* Each Feature corresponds to a Spec, which typically includes the Table name and may include other information such as the name of the key field (typically "ID"). | |||
* The Feature doesn't contain the Spec, but looks it up when needed (<code>GetMySpec()</code>). | |||
* Each Feature works with stored data via its Storage Row, which looks up the Table in the Table Registry using the Feature's Spec. | |||
Note that Storage doesn't ''have'' to use a database; the Dropin-viewer Dropin just uses an in-memory array generated from reading the "dropins" folder. | |||
Latest revision as of 22:26, 11 December 2022
|
the Features system
|
A "Feature", in this context, is a set of classes which work together to handle a particular type of data, traditionally represented by a table in a database. The class-set for each Feature is primarily organized around a descendent (subclass) of the Feature class.
Each Feature subclass represents a singleton object and has a SpecSlug() static method for identifying its table specs in the config data.
Pages
- /rendering: how Feature data is converted to display output (typically HTML)
- /access: how to access a Feature object
Related
- feature registry: translates URI slugs into Feature objects
- table registry: allows cross-referencing of tables within an app
Connections
A Feature that uses a Table doesn't know directly about that Table. The way the Table is accessed goes like this:
- Each Feature corresponds to a Spec, which typically includes the Table name and may include other information such as the name of the key field (typically "ID").
- The Feature doesn't contain the Spec, but looks it up when needed (
GetMySpec()). - Each Feature works with stored data via its Storage Row, which looks up the Table in the Table Registry using the Feature's Spec.
Note that Storage doesn't have to use a database; the Dropin-viewer Dropin just uses an in-memory array generated from reading the "dropins" folder.