Users should be able to override the default phlow tools for their custom Lepiter Page Types.

[botwhytho]

From Discord thread. Copying message content below.

LePage>>#asPhlowTool should delegate to LePageType hierarchy for the default (or custom) composite tools. Currently LePage>>#asLepiterPagePhlowToolFocusStatus: has the default composite tool defined as:

    ^ GtPhlowCompositeTool new
        addTool: (LePagePhlowTool new
            shouldFocusFirstSnippet: aBoolean;
            page: self);
        addTool: (GtPhlowTool default object: self)";
        addTool: (GtConnectorTool new object: self)"

This should be defined in LePageType and any subclass should be able to override
I already have 2 packages that use Lepiter pages to store arbitrary json in custom snippets. It would be nice to turn the Lepiter pages these packages use into having custom page types so that when I open those pages they are displayed differently. I have a third use case I want to work on which is a kanban board in Gt. I would want to store a 'board' as a Lepiter page, with lists and cards as snippet hierarchies. The default display of that should be a kanban board view, NOT a normal Lepiter page. Currently it doesn't seem possible to do what I want without the above refactorings in Gt

[botwhytho]

@JurajKubelka mirroring some Discord comments here that are relevant:

The functionality to provide the hook point is pretty quick to implement, I can open a quick PR for that. What I think feenk might need to assist with:
- Error handling & falling back to a sane default if one opens a database with an unknown page type
- A collection of GtAdvices and/or page in the Gt book that explains the various methods one may need to define/override if creating a custom LePageType subclass. I have a dummy custom page type working right now but if I restart the image or reload the database, I get deserialization errors and Lepiter marks the file tied to that page corrupt

Have encountered multiple errors along the way that are not clear at the outset and have required me to override various methods as LePageType is an abstract-ish class

[botwhytho]

PRs Created:

• lepiter Moving new classes from external package to GT packages. lepiter#15
• gtoolkit-world Adding a spotter search to add new named custom pages. gtoolkit-world#8

[botwhytho]

These PRs touch a LOT of things as one can't have custom page types 'partially' without things, small and large, breaking in various places. Some classes of importance:

• LeExampleCustomPageTypeExamples & LeExampleUnnamedCustomPageTypeExamples are the main test classes. Here we test that Lepiter can deal with unknown page types and doesn't error out on database reloads. If code is later loaded, these 'unknown' pages get loaded with their proper custom page types.
• LeExampleCustomPageType is a 'no-op' page type mainly used for tests in the above classes and documentation. It's class comment is thorough and this class can be copied with all of it's methods and later modified to more easily create new custom page types.
• LeSlideshowPageType a 'batteries included' example of a custom page type that provides useful functionality and is more than a 'template' like the above class.

[seandenigris]

This is exciting! I applaud your courage at fiddling deep into the system. I hope this gets quick feedback and hopefully merging. If so, I might resume some of my previous efforts that didn't seem to gain much traction.

Dynamic page types at it currently exists seems like a proof of concept. Many hooks are missing to have it be truly usable outside feenk, as reported previously on discord and again on discord:

After playing with custom Lepiter page types for a bit, I have the following raw report:

1. I am finding the "one size fits all" LePage with "has-a" type awkward, especially if you want to harness the moldable benefits of GT. There seem to be too many levels of indirection to get at the interesting objects. For example, to get custom views and inspector snippets, you have to either add them all to LePage, whether generally relevant or not, or constantly click through to a second object (the type).
2. I also suspect there are different classes of "types". Where the current mechanism might make some sense for types that can be converted one to another e.g. unnamed to named, there are cases, including mine (Transcript/notes belonging to specific instances of certain types of domain objects), where this isn't logical and so the benefits of the current scheme are unclear.

I don't have time at the moment to dig into this at the moment, but I wonder if you've addressed any of these related issues I've reported:

• [Lepiter]: Hook for Page Type to Customize Coder Add Ons #3488
• [Lepiter]: Page Type Updating Should Be Repeatable, Handle All Subclasses #2546
• LePageViewModel Creation Should Delegate to Page Type #2413
• [Lepiter]: Loading Fails for Custom Page Types #3163

On a tangent, I've been maintaining a Lepiter wish list including these and other ideas.

[botwhytho]

From going through the linked issues and the 'wish list' I see two scenarios (although they're not mutually exclusive) where custom page types seem to be useful:

• A user wants to modify some aspects/logic behind how a page works, but mostly use it as a 'normal' page. Customizing the new snippet list and adding values to the page shared bindings seem to fall under this.
• A user wants to leverage Lepiter features like JSON serialization, page visibility/searching from spotter, page links, etc. but they may be leveraging custom snippets (non-text, non-Pharo) and/or the focus may be on presenting a different UI, that looks nothing like a Lepiter page. My potential use-cases and interest seem to fall more under this category: slideshow pages, gt scenery pages, kanban board pages, modular synth (with Phausto + GtScenery 🤓 ), Time Tracking, etc.

[botwhytho]

I may be biased because I've thought a bit more through some use-cases that fall under that latter category, but those may be easier to support at the outset than the former. Seems like to support some features in the former you could clone + modify many interrelated classes. Doable but not ideal and can lead to code drift, having to maintain so much code 'out of band'.

[seandenigris]

Thanks for the thorough followup here and elsewhere!