Define pluggable template renderer strategy about ratpack HOT 5 CLOSED

I don't see a problem with the concept of a default render for producing pages, but I think multiple template renderers will be pretty common. I'd like to see some conventions for renderer APIs so that users will have a consistent way of working with them.

We also need to think about who is responsible for security-related features such as codecs, form tokens, etc. To be honest, it may be possible to incorporate HDIV as a module without too much effort. But if that's a separate module, how would it interact with other template renders provided by different modules?

Sorry, I'm raising more questions than providing answers, but I think it's important to get the questions down first.

from ratpack.

I don't see a problem with the concept of a default render for producing pages, but I think multiple template renderers will be pretty common. I'd like to see some conventions for renderer APIs so that users will have a consistent way of working with them.

It's not clear exactly what kind of value having a global renderer really has. Ratpack core can certainly ship an agnostic interface that implementors can use if they choose, but the question is how deeply the concept of "a renderer" should be in the framework. I'm starting to favour not having this assumption in there at all.

For the Groovy module, I think it does make sense to have default support for the Groovy template renderer, so that will stay there. Above, I'm only saying it should be cut out of the core.

We also need to think about who is responsible for security-related features such as codecs, form tokens, etc. To be honest, it may be possible to incorporate HDIV as a module without too much effort. But if that's a separate module, how would it interact with other template renders provided by different modules?

This is not something I know much about so can't give specifics. The one thing I can say though is that there will almost certainly be nothing for this in the core. We can certainly ship modules that users can opt in to, but they won't be in by default.

I'll need to defer to someone else's expertise on this for how ensuring that things are secure is handled.

The core idea here though is that Ratpack (core) is not doing very much for you – it's raw, so it's up to you to do the right thing. On top of that, we can ship some opt in modules that you compose a solution out of yourself.

Sorry, I'm raising more questions than providing answers, but I think it's important to get the questions down first.

All questions are welcome.

from ratpack.

So does not having a global renderer mean that the render() method disappears from core? If it does go, how would template rendering be done? To be honest, I've already forgotten how you 'render' a straight HTML file.

from ratpack.

So does not having a global renderer mean that the render() method disappears from core?

Yes. You'd inject your renderer as a dependency…

@Inject
class MyEndpoint implements Endpoint {

  MyFancyRenderer renderer

  void respond(Request request, Response response) {
    // …
    renderer.render("templateName", model, response)
  }
}

That is, there's nothing special about rendering. It's just another thing that an endpoint might do.

from ratpack.

No longer valid as there's no real rendering framework.

from ratpack.