WIP Draft for new result format interface design

[JeroenDeDauw]

Progress towards #125. This new interface will be an alternative to the existing one, not a replacement.

Based on work in the ModernTimeline extension.

No dedicated tests in this draft yet, though most code tested in
ModernTimeline via integration and system tests.

---

Design improvements over old ResultPrinter interface:

• Constructor injection possible
• Query result is simple data structure without global state access: testing possible
• Query result data structure allows extending logic and data without BC breaks
• Super simple interface without typically not needed methods/complexity
• Distinction between result format and result printer (called presenter in new interface)

---

Example registration:

$resultFormatRegistry->newFormat()
	->withName( 'moderntimeline' )
	->andMessageKey( 'modern-timeline-format-name' )
	->andParameterDefinitions( TimelineOptions::getTimelineParameterDefinitions() )
	->andPresenterBuilder( function() {
		return new TimelinePresenter( $timelimeFactory->getSomeCollaborator() );
	} )
	->register();

Example implementation:

class TimelinePresenter implements ResultPresenter {
	// Example of the now possible constructor injection
	public function __construct( SomeCollaborator $collaborator ) {
	}

	// Tests can create the $result data structure
	public function presentResult( SimpleQueryResult $result ): string {
		return 'construct string from $result data structure';
	}
}

---

TODO:

• Pass something for side effects (like adding JS to output) to presentResult
• Deal with PrintRequest (global access and constructor parameters)
• naming naming naming
• Are parameters part of the format or the presenter?
• unit tests
• integration tests
• Finish new registration system
• Make use of printers registered via new registration system
• (optional) Add ability to register just presenter class name for when DI is not needed
• (optional) Refactor some existing SMW format(s) to the new system

[krabina]

this is somehting for @s7eph4n

[s7eph4n]

I like the approach.

I am not sure though if I am a fan of that and-and-and-construct. One issue for me is that from their title it is not immediately obvious what those methods do. And generally, what's the advantage over just requiring four parameters?

[JeroenDeDauw]

@s7eph4n this is a fluent interface which you'll have seen before in places such as PHPUnits mock builder. Positional parameter lists have the disadvantage that (a) they are positional, so swapping parameters breaks things and (b) they are not named so hard to understand without looking at the function definition. Also some advantages when dealing with optional parameter and adding new parameters. And some disadvantages in that the required parameters are less obvious. All the usual fluent interface + builder pattern stuff really.

Naming can be changed and in the end how exactly the registry takes the info is an implementation detail. I'm much more interested in what info it takes.

[JeroenDeDauw]

@mwjames thoughts?

[kghbln]

@mwjames It will be super cool if you could have a peep on this and comment. My general impression as a user is that result formats need kinda more love. This may be the way to ....