Ferreteria/v0.5/feature: Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
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 | Each Feature subclass represents a singleton object and has a SpecSlug() static method for identifying its table specs in the config data. | ||
===Related=== | ===Related=== | ||
* | * {{l/ver|registry/feature|feature registry}} | ||
==Notes== | ==Notes== | ||
I'm still trying to figure out how this needs to work. There are currently Table Specs and registration of Features. A Feature doesn't know about Tables ''per se''; it only knows about its Storage Row, and the Storage Row may use a Table (thought it doesn't have to; the Dropin-viewer Dropin just uses an in-memory array). | I'm still trying to figure out how this needs to work. There are currently Table Specs and registration of Features. A Feature doesn't know about Tables ''per se''; it only knows about its Storage Row, and the Storage Row may use a Table (thought it doesn't have to; the Dropin-viewer Dropin just uses an in-memory array). | ||
Table specs are used/required by Card objects. | Table specs are used/required by Card objects. | ||
Revision as of 13:59, 8 March 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.
Related
Notes
I'm still trying to figure out how this needs to work. There are currently Table Specs and registration of Features. A Feature doesn't know about Tables per se; it only knows about its Storage Row, and the Storage Row may use a Table (thought it doesn't have to; the Dropin-viewer Dropin just uses an in-memory array).
Table specs are used/required by Card objects.