Tide feature and improved example

[kaj]

Provide a tide example similar to the other framework examples, with static files and error handling.

[prabirshrestha]

Latest tide contains the builder pattern so would be good to include for those too. I seem to be using builder pattern with render more. Here is the code feel free to copy paste.

https://github.com/prabirshrestha/rblog/blob/master/src/renderer.rs

[kaj]

Thanks for the review, @prabirshrestha !

Latest tide contains the builder pattern so would be good to include for those too. I see to be using builder pattern with render more. Here is the code feel free to copy paste.

Ah, it's new? So that's why you didn't use it in the code you contributed, I was wondering. Then I'll change the code to use it.

[prabirshrestha]

builder pattern was only introduced in 0.12. My PR was before that version hence didn't include the builder example.

[kaj]

Since tide provides the http-types crate as tide::http, I'm considering a feature tide that exposes the same functionality as the http-types feature, but without the need for a direct dependency on http-types. Since tide is still in 0.x, it would probably be a tide012 feature, to make room for breaking changes.

And if I do that, it might make sense to move the traits and impls in ructe_tide.rs from the example to the feature.

[kaj]

I'm thinking of moving the contents of ructe_tide.rs into an actual tide feature of ructe, but before that: Two review questions for @prabirshrestha (and/or anyone else reading this) :

Is Render and RenderBuilder good names for the trait? Or would RucteResponse and RucteBuilder be better since it would be more clear what they would be about?

What should the Builder variant of the render methods return? For error handling, it might be better to return an std::io::Result<ResponseBuilder> and let the caller handle any errors? Or the render and render_html methods could finalize he builder, returning a tide::Response? That way, it could handle errors by returning a response containing the actual error rather than logging the error and returning a "generic" internal server error response.

[kaj]

Another thing I have realised: the tide framework seems to make it possible to write the response body directly onto the response buffer (the same buffer as the response header is written to) rather than to a separately allocated buffer which is then copied onto the response buffer. I think that is worth some consideration.

Followup: Probably not worth doing. For one, that would hide the length of the body from the impelementation, forcing it to either use some extra buffer anyway or fall back to chunked encoding. Also, creating a Body from a &'static [u8] also copies the data to an owned vec in the Body.

[prabirshrestha]

adding @yoshuawuyts for thoughts on this.

I do like Render and RenderBuilder as name.

+1 for streaming directly to response stream.

current PR is already is good state and given it is an example and no one will be taking a dependency on it I don't have strong opinions to make sure we get the apis right now.

[kaj]

Yes, you are right. Time to stop fiddling with details and merge this.

[prabirshrestha]

@kaj could you release a new version so I can take dependency on the new feature.

[kaj]

@kaj could you release a new version so I can take dependency on the new feature.

Yes. I intended to get #88 (join_html and join_to_html) done before the release, but that was harder than I thought, so I'll make a relase (hopefully in a few hours) without it.