2022/05/30/more data-class rubberducking

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)

Again with the indecision over naming things...

...which then twines into indecision over underlying design...

[12:10 PM]

So, right now there are two ways of handling the display of a record.

One is premised on the idea that you're working with records one at a time. A record corresponds to a page.

The other is premised on the idea that you want to see multiple records, and possibly operate on subsets of them (e.g. with checkboxes or action-links or whatever). The exact format doesn't matter, though it's usually a table, with one record per row (but we sometimes want to see multiple records references in a single line... I've been doing that as a separate area of functionality, but it may be worth keeping in mind as a variant on this theme).

[12:11 PM]

This dichotomy is pretty easy to handle at the Card level -- I just have one class for the Page display and another for the Line display; the Rows class chooses which one to spawn.

[12:13 PM]

The problem I've bumped into has to do with the Rows classes.

It'd be convenient if I could do the same dichotomy with Rows classes -- one for Page view, one for Line view... but then I need something higher up to choose which class, and for now I've decided that the Rows class needs to be where the bifurcation happens (because the next level up is the Bank, which splits by type of I/O - display, storage, or native (internal) -- which starts to get messy when you're also doing variations on the same I/O type).

[12:14 PM]

So instead of the obvious, tidy class-dichotomy, we have (a) standard Rows class which only knows one type of display (so far, have only used this for Page view), and (b) a dual-mode type which can either display a single Page Card or multiple Line Cards.

[12:15 PM]

So first off, this messes up the naming a bit.

[12:16 PM]

I want to have "line" be the slug I use for naming the Rows subclass -- but that's confusing, because it doesn't just handle Line view; it can handle both Line and Page views, choosing which one to use depending on context.

[12:16 PM]

Maybe "what do I mean by 'context'?" is a good question for me to be asking...

[12:20 PM]

The most obvious context is whether a specific row has been requested. If not, then the Bank (well... ok, Feature, which is like a Bank that registers itself as a thing which can be invoked by URI data) assumes we want to see all of the rows...

[12:22 PM]

...okay, there are two stages to this:

(a) the process of selecting the rows to be displayed (can be in code -- e.g. an Account page will show all Groups assigned to said Account -- or, in the future, user-configurable (e.g. show only the first 100 records, or those between two dates, or whatever)

(b) the process of displaying whatever is in the recordset

[12:25 PM]

So first we have an outer method which looks at the URI, decides whether it's requesting a specific Row or multiple Rows, selects the data, and then passes it on to a different method -- either a Page-Mode-display method or a Line-Mode-display method -- which then loads the appropriate Card objects and iterates through whatever data it has been given (which should only be a single Row if it's a Page-mode Card).

[12:28 PM]

The design question I was bumping into: are Page and Line modes just the most common examples of what might in some cases be multiple different modes I'd want to be able to support? E.g. that "keep in mind" I mentioned earlier -- maybe we want to be able to page-view a record, to multiple-lines-list records, and to inline-list them as well (e.g. just the name, or name + some kind of quick stat, linked to the page).

[12:30 PM]

Thing is, there are two distinct modes at work here, even in that trio. One mode iterates; the other doesn't... or at least shouldn't need to.

[12:30 PM]

Like... we can make assumptions, in Page mode, that certain things won't be needed. There's no point in a header or footer when you're only showing one thing.

[12:31 PM]

But is it simpler to stub in the functionality regardless, or simpler to only add it in when needed?

[12:32 PM]

I've been assuming it's simpler to add it in when needed -- because if you do need Line as well as Page, then you need knowledge of two different Card classes. If you only need one view, then you only need one Card class -- which is how all the other Rows classes work.

[12:38 PM]

But let's say that once we get past single-mode, we're not thinking in terms of always exactly two display-modes. What if we wanted to support, say, three different views -- page, lines, and inline (see above for an example). (edited)

[12:39 PM]

One thing we can simplify is to just always iterate. If it's a single row, we'll just only iterate once; same result. The header and footer can be blank.

[12:42 PM]

For just that part, we don't even need a subclass to handle more than one mode of data-management; just build iteration into the base class.

What does change is how we configure each Rows class's corresponding Card class(es). The base Rows class would only have one; the subclass would need to be able to specify different Card classes depending on display mode.

[1:07 PM]

So, the question is how hard I want to push to bake in the idea of multiple Card classes now, vs. just implementing a two-mode system for now and saving multiples for later.

(...and on that note, I must go shopping and then probably eat something.)

[3:03 PM]

I think that if I'm actually remembering to ask "do I need to solve this problem now, or can it wait?", that's a good opportunity to try waiting rather than risking yet more cascading refactors.

[3:04 PM]

So, next: naming.

[3:05 PM]

I was calling it "bimodal", which is a tad awkwardly long for my taste... how about "dual"? I think my brain may find that less squicky.

[5:39 PM]

Oh arf, I have to be careful about where the content template string is set, because it needs to be different depending on which mode -- so I can't just cache the Template object with that string set in it; I've got to update it whenever the mode changes... bleh.

...and when these two traits are used together, one trait from A needs to override one from B, and one from B needs to override one from A...

I think PHP provides a syntax for doing exactly that, but I have to figure it out and maybe make a compound trait so I don't have to paste lots of code whenever I use them together.