Ferreteria/v0.5/feature: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
No edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=the Features system=
{{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)
==Notes==
* [[/access]]: how to access a Feature object
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).
==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.


Table specs are used/required by Card objects.
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

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.