`updatePage: to:` Should Return a Proper Page Object

[seandenigris]

It just returns a string

[khinsen]

That's the way it's supposed to work. There are no page objects, contrary to the old Wiki implementation in ActivePapers.

[seandenigris]

Oh I see. I wonder about that change. One of the central premises of GT is that the IDE is object oriented i.e. no monolithic tools, but each object carries interesting views along with it. A page seems to me to be the most central domain concept of a wiki, but if there is no type for it, there is no way to have e.g. a live, custom GT view for it in the inspector, unless one accesses it from within the pre-built browser. What is the motivation behind this change? Am I missing something?

[khinsen]

That's a good fundamental question, and I certainly don't claim to have found the best answer for WIkis yet.

A page is certainly a fundamental domain concept of a Wiki, but then I could argue that an element is a fundamental domain concept of an array, and yet there is not ArrayElement class in Pharo, for good reasons. So the question is how fine-grained OO modelling ought to be.

After decades of seeing overengineered code (mostly Python) with tons of classes that had no significant functionality, I have adopted a minimalist point of view in which I only define a new class if there's a real need for it. In the old ActivePapers framework, I needed APWikiPage because the only way to view/edit pages was the GToolkit inspector, so I needed an object to inspect, as you describe. With the new WkWikiBrowser, this need went away.

Note that my IpfsWiki class (over at https://github.com/khinsen/ipfs-pharo/blob/master/src/IPFS-GToolkit/IpfsWiki.class.st) does have its own IpfsWikiPage class because there is a good reason for having one: storing pages as separate IPFS data items. This illustrates that a specific Wiki implementation can have a page class even though the abstract framework doesn't.

As you point out, one functionality that requires a page class is inspecting an individual page. But does this really add to the experience of working with WIkis, given that the page object would just be a view-specific label added to a string?

[girba]

Interesting conversation!

What should be first class is an old philosophical debate, in fact. With moldable development we tend to transform it into a practical problem. Whenever you want to view an object, you want a custom view. To build a custom view you want a first class.

A further reinforcing constraint comes from the fact that we mostly compose the UI out of views. That means that whenever I have the need to display something in a special way, there should be a view for it and that, of course, should be hosted in a first class entity.