GeePawHill

GeePawHill, 1 day ago

Recall that the two primary entry points for the business logic are childrenFor(...) and bodyFor(...), both members of the primary business object, CurryTree itself.

childrenFor()'s job is to populate the tree that shows on the left-hand side of the screen. When any item there receives focus, bodyFor() then supplies the data for that particular item.

fun bodyFor(responder: Responder, handle: String, slug: String) { val bodyPath = Path.of(slug) if (bodies.exists(bodyPath)) { val body = bodies.read(bodyPath) responder.ok(body.blocks) } }

GeePawHill, 1 day ago

childrenFor() does this by identifying the user, and asking the user what children a given tree node has.

bodyFor() just goes to the sea of page bodies out there, and loads one up.

Both behaviors are incorrect/incomplete, according to my current thinking.

GeePawHill, 1 day ago

Issues: 1) some users can edit things other user's can't. 2) some pages (and ultimately parts of pages) can be seen only when the user has met certain criteria. 3) users are members of a cohort, which should be the real tree of the course. 4) Users may be members of multiple cohorts, and have different rights in each of them. 5) The current system can show different users different trees, and that is a mistake for several reasons, caused by me not thinking of a better mechanism.

It's a lot.

GeePawHill, 1 day ago

One further issue: when an editor saves a change, we want that change to ripple out to all users of that cohort. (This is part of why we don't want different trees for different cohort-members.)

GeePawHill, 1 day ago

So, my current conception, and it's just a conception at this point, goes like this.

There is a cohort and some users, who may or may not have various roles in that cohort. The cohort has a single tree in it.

The childrenFor() first goes through the cohort to collect all children of the node being asked for, then filters that list through the user. The user's role and their current progress is used in the filter.

GeePawHill, 1 day ago

And bodyFor() works much the same way: first find the main body/text/notes/history info for the page, then hand it off to the user to add any user-specific history to it.

GeePawHill, 1 day ago

And finally, instead of working with individual slugs, let's rework the tree's find capability to always use whole paths.

(This is how we support a user being part of multiple cohorts: the first element of that path is the slug for a given cohort.)

GeePawHill, 1 day ago

Now, I'm a million miles away from having all that. And the MMMSS path is far from being clear. BUT, there are some things that seem apparent right from the get-go.

I'm going to go after them today.

Fortunately, most of this is pure business logic, and as such, I have lots of TDD capability.

So let's take some steps.

GeePawHill, 1 day ago

Step: The bodyFor() is currently returning, via responder, a list of blocks. That's over-simple. It wants to be returning a new data class, PageBodyResponse.

Let's do that now.

GeePawHill, 1 day ago

@lewiscowles1986 I am purposefully building for very modest numbers per cohort, especially since users of a particular cohort will "age out", rarely returning to the material once they finish working with it. Think "active users of all cohorts at any given time" on the order of a few thousand, max.

GeePawHill, 1 day ago

@lewiscowles1986 I like the visuals of a tree. One of the things I least like about rigs like gitbooks or notion is how they handle or fail to handle trees. Instead of generalizing the idea of a tree-shaped collection of material, they support a crude and ineffective two-level "looks like a tree for two minutes" thing.

GeePawHill, 1 day ago

So simple it's not worth showing code. The new PageBodyResponse is simply a data class whose only value is the old way I responded. :)

Step: Introduce Cohort, which will now hold the tree, instead of per-user trees.

GeePawHill, 1 day ago

Step: Use the Cohort to load the body. Do it the same way we do it now, we're just re-directing, not changing behavior yet.

GeePawHill, 1 day ago

Okay, that step came close to creating panic. No worries, it's all okay now.

The new bodyFor(...) looks like this.

The cohort's version of bodyFor(...) is nearly identical to the old bodyFor(...).

I thought I might have to re-work the initializeForDemo heavily, hence my temporary panic. In fact, all I had to do was add one Cohort with a hardwired name.

@Serializable data class Cohort(val pages: PageHeaderTree = PageHeaderTree()) { fun bodyFor(responder: Responder, bodies: Store, user: User, slug: String) { val body = bodies.read(Path.of(slug)) responder.ok(PageBodyResponse(body.blocks)) } }

GeePawHill, 1 day ago

Some notes about the badnesses here.

1. WTF w/all the Path.of(...) calls?
2. Ummmmm, unhappy paths, GeePaw?
3. Hardwired cohort path of "cohort".
4. Do you have any real tests for this, old man? (Kinda)

Still, even with all that, it's a legit step. Green before, green after, working before, working after.

GeePawHill, 1 day ago

The real issue here is #1, the ubiquitous use of Path.of(...). There are two things going on here.

1. I used "slug" everywhere, thinking of it as the leaf node of anything, instead of as a full path, and requiring it to be globally unique.

2. The various tree "finds" and their clients all work with TreeLocation, when, really, they should be working with Path.

<sigh>

Feels a little daunting.

GeePawHill, 1 day ago

#2 above is conceptually provided for.
#3 above falls out from #1
#4 is just that I'm relying on some higher-level tests rather than microtests. It needs thought, but just a little bit of effort.

But that #1 feels like a real blocker.

GeePawHill, 1 day ago

Anyway, I'm going to pause for a while.

As always, the repo is at https://github.com/GeePawHill/currytree

All comments, questions, controversies and QWANs are welcome, just speak right up!

GeePawHill, 2 days ago

@GottaLaff Have you been hit hard by the vaccine/booster before? My second booster gave me a two-hour long raging fever, and laid me up for the next day. Most of them have been nothing, before and after.

GeePawHill, 4 days ago

@GottaLaff Visiting family in prison is very time-consuming.

GeePawHill, 5 days ago

Pablo Casals, in his 80s, asked why he practices every day. "Because I think I'm getting better."

Pat Metheny, why he has restricted his synth-guitar to just two voices, "I don't want to try a new voice until I feel I've mastered these two."

Somerset Maugham, on the definition of a novel: "A prose work of a certain length, that has something wrong with it."