Decouple logic from presentation.

[emlynwest]

Controllers should return a standard data object (of some sort), the decision how to render it should be handled externally (configuration, info in the data object, "Accept" request header, extension, etc)

[sagikazarmark]

I agree about decoupling, but I am not sure data serialization should be removed from the controller. If the controller has the ability to decide about rendering, what's the point in not rendering the content in the controller?

I fear this would make controllers an abstraction layer over other data related layers.

[sagikazarmark]

Related: https://github.com/pmjones/adr

[WanWizard]

The problem I want to address is multi-channel output. One of the biggest design flaws with regards to v1 controllers is that a Controller is either a REST controller, or an HTML Controller. And you have to go through all sorts of hoops when you want both without having to replicate code.

Consider for example a REST CRUD API that doesn't accept and return JSON when called by a browser, but accepts a form POST and returns HTML. Which exactly the same Controller code.

I am familiar with Paul's work, and ADR comes close to the direction I'm thinking about, but in his proposal the Responder still maps one-to-one to a specifc template and therefore output type. But it does indeed decouple the rendering itself from the Controller, and that is my primary goal.

[WanWizard]

I can live with something like this though: https://github.com/pmjones/adr/blob/master/example-code/Web/Blog/Responder/BlogBrowseResponder.php with the added comment that I would like to be able to restrict the available format list and influence negotiateMediaType() from the Controller...

[sagikazarmark]

Well, the standard data object (of some sort) is what triggered me, but Response is kind of a standard data object after all.

My concern is that we introduce yet another API boundary with this and if it becomes a limitation for someone, there is exactly 0 things we can do about it: no extensions, otherwise it becomes incompatible with the rest of the "Responders", etc.

[WanWizard]

What kind of limitation are you thinking about?

The idea whas that the controller returns an object that contains the raw return values (f.e. ['name' => 'John']). It is then up to the renderer, based on "some logic to be determined", to convert that data into output, i.e. to create a Response with a View (which generates HTML), or a Response with a JSON body, or...

Whatever the renderer is, what it outputs, and how it does that, is enterly up to the developer, as long as it implements "RendererInterface" or something. The framework can supply a handful of standard renderers for the usual output types, to get the developer going.

[emlynwest]

Currently working on this and going down that line. There's a FormatterInterface, something along the lines of:

<?php
namespace Fuel\Foundation\Formatter;

use Fuel\Foundation\Request\RequestInterface;
use Fuel\Foundation\Response\ResponseInterface;

/**
 * Defines a common interface for taking a controller result and formatting that for return to the client.
 */
interface FormatterInterface
{
	/**
	 * Should return true if the formatter is able to handle the current data
	 */
	public function canActivate(RequestInterface $request, ResponseInterface $response) : bool;

	/**
	 * Should produce a ResponseInterface object that contains the formatted data and any necessary headers.
	 */
	public function format(RequestInterface $request, ResponseInterface $response, $data) : ResponseInterface;
}

Still WIP and likely to grow/change as I start implementing the actual formatters.

[emlynwest]

My thinking is that Foundation can provide a set of "common" ones, JSON, HTML, etc, and then have it set up so the developer can easily turn this on and off, add their own and set the order the formatters are checked in.

[emlynwest]

I've created a couple of formatters along my current lines of thinking for this (just the filters, not anything that actually uses them), it's on https://github.com/fuelphp/foundation/tree/output_formatting if you want to take a look.

https://github.com/fuelphp/foundation/blob/output_formatting/src/Formatter/Noop.php as a dummy pass-through one and a json related one for APIs, etc, https://github.com/fuelphp/foundation/blob/output_formatting/src/Formatter/HttpAcceptJson.php

[sagikazarmark]

Do we want to keep that stupid Interfacesuffix? 😝

[sagikazarmark]

@stevewest if you create a pull request, we can comment on it :)

[emlynwest]

@sagikazarmark So we should be using an I prefix? ;) And there will be a pull request when I have something that's functional.

[sagikazarmark]

No. Just Formatter

I think I am near 1000 sharing of this link: http://verraes.net/2013/09/sensible-interfaces/