Add TemplateResponder trait for integration with actix-web

[zizhengtai]

This is similar to what actix_web::AsyncResponder does. It enables us to call .responder() on a template to render it into an actix_web::HttpResponse. This is advantageous over the current approach (implementing actix_web::Responder for T: Template) because the current approach doesn't allow returning templates with references to local variables. Please see the added test for what I mean.

[djc]

Should we remove the current approach, then, or does it address a different use case?

[zizhengtai]

The current approach can be removed. I just don't know if you are fine with the breaking change.

…

On Sun, Jan 27, 2019, 5:00 AM Dirkjan Ochtman ***@***.*** wrote: Should we remove the current approach, then, or does it address a different use case? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#205 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE9qWJvd9iUBGKUMxdvIXqUJGyX4iEtJks5vHaLkgaJpZM4aUj3p> .

[gregelenbaas]

I don't think the current approach should be removed. I like the addition for flexibility but I think it would cause unnecessary breakage as well as no longer allowing the shorter syntax when local variables do not need to be computed.

[djc]

Closing, no longer necessary (see #204).

[zizhengtai]

@djc, I think there is a misunderstanding. This PR isn't doing the same thing as #204. #204 only provides a way to return a template without specifying the concrete return type (but instead with a impl Responder), but it doesn't solve the problem that the returned template cannot contain references to local string slices. The example in #204 compiles only because the reference has static lifetime; if you change it to a 'a (which is what this PR allows for), the code doesn't compile.

Could you please reopen this PR and review it? Thank you.

[zizhengtai]

Any updates on this?

[djc]

So as I understand we can only generate code for the new approach, remove the old respond() implementation and the code generation for the stuff that's there now, and almost all of the current users' code would stay working. Can someone explain to me why that might not be true?

[djc]

I'll just merge this and do some follow-ups.