2021/12/17/The Great Data-Class Restacking

Codeblog 2024/11/14 untangling setup calls - mostly just notes to myself 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

Okay, it's finally time to do this. The strain from having the old data-classes kind of dangling off one side of the PortBank classes has been building for some weeks now, and I finally got to the point where it didn't make sense to keep trying to spackle over the gaps.

The existing class structure is in two parts. There's the old set of classes which goes back to before Ferreteria even had a name, and there's the newer set of classes around the PortBank class. The old classes still have a role to play, but a large chunk of their functionality needs to be moved into the Storage PortRow classes.

The Old Way

The database I/O classes consist of basically:

• Database
• Table
• Rowset
• Record

Applications would descend from Table and Record (and sometimes Rowset) to create app-specific functionality, which (obviously) had to be oriented around specific tables (or queries) in the database. (This tethering has not actually been a problem yet, although I imagine it eventually will be.) URIs then directed the application as to what Table was going to be the focus of the current activity, and generalized code would ask the Table to please display itself and do whatever else needed to be done based on other data in the URI (or in cookies, etc.)

What has been a problem -- and what led me to create the PortBank classes in the first place -- is the following:

• Values in Records are kind of ambiguous as to whether they're in as-received (from the database) format or an internal format suitable for calculations. These two formats are identical often enough that it wasn't a problem at first.
• Record fields do not know how to translate certain kinds of value into database-writable values; the app must write its own code anytime a field needs special treatment.
• Record fields also do not have any standard way of managing screen I/O; this had to be hand-coded.

Those needs led to the creation of the PortRow classes, which handle translation to and from Storage and Display formats.

However, we're now left with a lot of specialized Table and Record descendants which do some of the work which should be in the PortRow, and a lot of tight dependency between the Database class and how the Records are loaded.

The New Way

It's time to simplify the data-storage I/O classes back down to utility-level functionality, knowing nothing about the fields they're reading or writing, and let the PortRow classes handle all of the app-specific and field-specific stuff (as they are increasingly doing already).

The most dramatic part of this is that instead of loading a Table from the URI and asking the Table to do stuff, we need to load the associated PortBank class and ask it to display its output. It can then do whatever it thinks needs to be done, which typically will involve loading a dataset and displaying it but could be something much less data-driven.

I expect this structure will offer a lot more flexibility in terms of how each feature (formerly Table) behaves. In theory, we could have a PortBank descendant that isn't closely tied to a specific Table; I need to make sure to set up the class-structure that way...

To-do list for now, then:

• Change the URI-processing code so it uses a PortBank class instead of a Table class.
• Move all remaining specialty Table/Rowset/Record code into appropriate PortRow classes.