Ferreteria/v0.5/feature: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
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.
* a SpecSlug() for identifying its table specs in the config data
* an ActionKey() for being identified as the object to handle URL data
===Related===
===Related===
* The {{l/ver|registry/table|table registry}} involves both {{l/ver|table}}s and {{l/ver|table/spec|table specs}}.
* {{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.