Slim: Interface for content renderers

[geggleto]

Related to: https://github.com/slimphp/PHP-View/issues/24

It does make sense for Slim as a project to have an interface that defines a set of common data access methods.

Here is what I was thinking based upon TwigView.

namespace Slim\Views;

interface ViewRenderer {

    public function fetch($template, $data = []);

    public function render(ResponseInterface $response, $template, $data = []);

}

We could add get/set for global template values.

[mathmarques]

:+1:
I think we could extend \ArrayAccesson this interface to get/set global values (like TwigView)

[geggleto]

Yeah I think that would be a good idea, php-view doesn't but it was something that was being asked for.

[dopesong]

I think it should be in separate repo - like container-interpop interface.

[geggleto]

@dopesong This one is suppose to be for Slim specific render implementations... It seems rather wasteful to have a separate repo for a single interface.

[dopesong]

I'm using slim for APIs so it's wasteful for me to have such interface with Slim. I think Slim should stand for its name and should not cary what is not needed. As twig view and your php-view are just 3-rd party libs in my opinion they should implement some interface which works with PSR-7 and should not be attached to Slim. :)

[rachellcarbone]

Are we able to create custom views currently without this interface? I just upgraded from v2 to v3 and am trying to re-implement a custom JSON view that uniformly formats all responses. I'm having a hard time figuring out how to connect it to the API.

[silentworks]

@rachellcarbone yes currently you can create custom views, take a look at the Twig-View or the PHP-View to see how its done. How was the custom JSON view implemented in v2? was it a hook or a middleware or just manually called in each route callable?

[rachellcarbone]

@silentworks Hello! It was called by $app->render manually in each route to complete the method. I was hoping to implement it in a similar way.

[rachellcarbone]

@silentworks Thank you I was able to figure out how to add it as a container view and use render by looking at the PHP-View. Thanks for the help!

[kminek]

i totally agree with @dopesong - view renderers are third-party libs. i guess we will have to wait for PHP-FIG interface for view renderer in MVC :)

[geggleto]

@kminek we will still provide renderers by default ;)

[kminek]

@geggleto why should Slim provide abstraction for third-party library? if we would like to take that
path - why not provide abstraction for configuration or database access? Slim is micro-framework
and as dopesong pointed "should not cary what is not needed"

[geggleto]

@kminek traditionally we provide Twig and PHP renderers. In order to facilitate further 3rd party packages we need a defined interface published ;)

[geekish]

I see no problem in having one extra interface in Slim as long as it is completely optional to use.

[geggleto]

@geekish would be 100% optional.

It will just allow us to keep a standard API between different rendering libraries... ie TWIG, PHP ... etc

[geekish]

@geggleto Just had to throw my two cents in since it seems there are a few against this. I see no problem with one extra interface when the alternative is creating a separate package just for the interface. I know Expressive does this but they have some helpers in there IIRC.

[dopesong]

So we have Middlewares, we have PSR-7. What's the point of additional interface? Still, can't understand that while you can achieve the same thing with a more global approach. :)

[mathmarques]

I think this can be closed as discussed https://github.com/slimphp/Slim/pull/2445