How to use it with Mount, does it support it?

  let mut hbse = HandlebarsEngine::new();
  hbse.add(Box::new(DirectorySource::new("./views/", ".hbs")));
  if let Err(r) = hbse.reload() {
    panic!("{}", r.description());
  }

  let mut router = Router::new();
  router.get("/", index);

  let mut mount = Mount::new();
  mount
    .mount("/", router)
    mount("/css/", Static::new(Path::new("static/css/")));

   println!("Server running at http://localhost:3000/");
   Iron::new(mount).http("localhost:3000").unwrap();

Here how can I add hbse to mount or how to get them work together?

It's easy enough to add gzip to non-handlebars iron responses: https://github.com/gsquire/compress (which might be a great example of how to use the other library)

BUT, when using handlebars, it's much trickier to do. I was working on my own AfterMiddleware handler that would mutate the output of handlerbars.. but still being new to Rust, and the AfterMIddleware piece has been a little tricky. Should be fairly simple given you already have that piece working if it's directly integrating into the library... and probably an appreciated feature by all. https://github.com/alexcrichton/flate2-rs

Here's the snippet of code I already have working, to be added to the AfterMiddleware, potentially adding gzip as an extra option: let raw_accept_encoding = request.headers.get_raw("Accept-Encoding").unwrap();

    for accept_encoding in raw_accept_encoding
    {
        println!("raw_accept_encoding: {}", str::from_utf8(accept_encoding).unwrap());

        if str::from_utf8(accept_encoding).unwrap().to_lowercase().contains("gzip")
        {
            response.headers.set(ContentEncoding(vec![Encoding::Gzip]));
            let mut encoder = GzEncoder::new(Vec::new(), Compression::Default);
            encoder.write_all("Insert Handlerbars output here");

           let compressed_bytes = encoder.finish().unwrap();  //except don't unwrap
            //then return compressed_bytes. 
      }

}

Hey!

This library is awesome - thank you for your continued work on it.

I'm making this issue to ask if you think it is worth implementing Handler for Template? Currently I am doing something like this in my code:

pub struct TemplateHandler {
    path: &'static str
}

impl TemplateHandler {
    pub fn new(path: &'static str) -> TemplateHandler {
        TemplateHandler { path: path }
    }
}

impl Handler for TemplateHandler {
    fn handle(&self, _: &mut Request) -> IronResult<Response> {
        let mut resp = Response::new();
        resp.set_mut(Template::new(self.path, ())).set_mut(status::Ok);
        Ok(resp)
    }
}

// Mount the templating
mount.mount("/",
            router!(
    get "/" => TemplateHandler::new("index"),
    get "/kmeans" => TemplateHandler::new("kmeans"),
    get "/dbscan" => TemplateHandler::new("dbscan"),
));

Maybe I'm missing the point but I think it would be nice to provide this behavior within this library. I know there are many use cases that will not simply be rendering a web page without providing new content. But I think this is common enough that it is valuable.

An alternative could be to implement Handler for a new wrapper type as I have - perhaps called RenderTemplate?

In any case, it is not too much extra code to add on and the library is very useful as is!

DirectorySource treats the path argument in a very literal way. Specifically if there's a file "templates/index.hbs", then

DirectorySource::new("templates", ".hbs")

will register template "/index", but

DirectorySource::new("templates/", ".hbs")

will register template "index". I'd expect both to do the same thing (without initial slash), because the path points at the exact same directory.

I'm currently writing an application that should run as a single binary. Right now I'm acquiring the RwLock for the registry explicitly, and call register_template_string(..., include_str!(...)) for each template.

I've found two rather easy to fix usability problems specific to my usecase:

• When trying to use HandlebarsEngine::from with a custom registry, it cleared out all manually registered templates.
• Handlebars-rust still tries to stat against a directory, but in my case this isn't necessary.

And then the idea of loading/parsing/compiling templates at compile-time comes to mind, but I suspect that the necessary APIs aren't stable yet in Rust, and that it's too late for those kind of major feature requests.

Regarding the two usability problems, I am not sure what to do. Perhaps HandlebarsEngine could make the prefix and suffix fields of type Option<String> to indicate that the raw registry should be used? Such a state would also disallow usage of reload and disable its initial invocation.

Handlebars-iron now builds with the newest glob crate that returns Paths of the new type. env::current_dir() of the standard library still returns old_path types, so this is only a partial reform.

So when using the serde_type feature I get a compilation error. The compilation error actually originates in the handlebars crate but since I do not depend on it directly I was not sure where I should submit the issue.

Compiling handlebars v0.18.1
error: a type named `Json` has already been imported in this module [--explain E0252]
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/template.rs:11:5
   |>
9  |> use serialize::json::Json;
   |>     --------------------- previous import of `Json` here
10 |> #[cfg(feature = "serde_type")]
11 |> use serde_json::value::Value as Json;
   |>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: a trait named `ToJson` has already been imported in this module [--explain E0252]
 --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/registry.rs:9:5
  |>
7 |> use serialize::json::ToJson;
  |>     ----------------------- previous import of `ToJson` here
8 |> #[cfg(feature = "serde_type")]
9 |> use serde::ser::Serialize as ToJson;
  |>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: a type named `Json` has already been imported in this module [--explain E0252]
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/render.rs:10:5
   |>
8  |> use serialize::json::Json;
   |>     --------------------- previous import of `Json` here
9  |> #[cfg(feature = "serde_type")]
10 |> use serde_json::value::Value as Json;
   |>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: a type named `Json` has already been imported in this module [--explain E0252]
 --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/helpers/helper_each.rs:4:31
  |>
2 |> use serialize::json::{Json, ToJson};
  |>                       ---- previous import of `Json` here
3 |> #[cfg(feature = "serde_type")]
4 |> use serde_json::value::{self, Value as Json};
  |>                               ^^^^^^^^^^^^^

error: a type named `Json` has already been imported in this module [--explain E0252]
 --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/helpers/helper_lookup.rs:4:5
  |>
2 |> use serialize::json::Json;
  |>     --------------------- previous import of `Json` here
3 |> #[cfg(feature = "serde_type")]
4 |> use serde_json::value::Value as Json;
  |>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: a type named `Json` has already been imported in this module [--explain E0252]
   --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/context.rs:7:31
    |>
2   |> use serialize::json::{Json, ToJson};
    |>                       ---- previous import of `Json` here
...
7   |> use serde_json::value::{self, Value as Json};
    |>                               ^^^^^^^^^^^^^

error: duplicate definitions with name `call`: [--explain E0201]
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/helpers/helper_each.rs:87:5
   |>
87 |>     fn call(&self,
   |>     ^
note: previous definition of `call` here
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/helpers/helper_each.rs:17:5
   |>
17 |>     fn call(&self,
   |>     ^

error: duplicate definitions with name `wraps`: [--explain E0201]
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/context.rs:79:5
   |>
79 |>     pub fn wraps<T: Serialize>(e: &T) -> Context {
   |>     ^
note: previous definition of `wraps` here
  --> /home/azerupi/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.18.1/src/context.rs:73:5
   |>
73 |>     pub fn wraps<T: ToJson>(e: &T) -> Context {
   |>     ^

error: aborting due to 2 previous errors
error: Could not compile `handlebars`.

At first sight, it seems as enabling serde_type does not disable rustc-serialize causing the double definitions.

EDIT: It seems to compile fine with default-features = false but intuitively I would have assumed that just enabling serde_type would take care of this. Would it be possible disable rustc-serialize when serde_type is enabled?

Currently, modifying the response of an Err(IronError) to have a template is not processed by the AfterMiddleware in this package, and the response body stays empty.

To process errors as well, catch needs to implemented besides after.

Is there way to use DirectorySource as MemorySource?

I tested: https://github.com/sunng87/handlebars-iron/blob/master/examples/server.rs

wrk -t12 -c400 -d2s http://localhost:3000/mem
90k rps

wrk -t12 -c400 -d2s http://localhost:3000/
30k rps

I saw perfomance issue - I/O.

I try registering Helper

#![allow(dead_code)]
use hbs::{HandlebarsEngine, DirectorySource};
use handlebars::{Handlebars, RenderError, RenderContext, Helper, Context};

pub fn template_render(paths: Vec<&str>) -> HandlebarsEngine {
    let mut template = HandlebarsEngine::new();

    // Add helpers
    template.register_helper("link", Box::new(link_helper));

    // add a directory source, all files with .html suffix
    // will be loaded as template
    for path in paths.iter() {
        template.add(Box::new(DirectorySource::new(path, ".html")));
    }

    // load templates from all registered sources
    if let Err(r) = template.reload() {
        panic!("{}", r);
    }
    template
}

And I got error:

error: no method named `register_helper` found for type `hbs::HandlebarsEngine` in the current scope
  --> src/middleware/render.rs:11:14
   |
11 |     tempalte.register_helper("link", Box::new(link_helper));
   |              ^^^^^^^^^^^^^^^

error: aborting due to previous error

How to fix that?

Shown by the following example:

Add the following two files to the examples and examples/templates as array.rs and array.hbs respectively:

extern crate iron;
extern crate env_logger;
extern crate handlebars_iron as hbs;
extern crate rustc_serialize;

use iron::prelude::*;
use iron::{status};
use hbs::{Template, HandlebarsEngine};
use rustc_serialize::json::{ToJson, Json};
use std::collections::BTreeMap;

struct Team {
    name: String,
    pts: u16
}

impl ToJson for Team {
    fn to_json(&self) -> Json {
        let mut m: BTreeMap<String, Json> = BTreeMap::new();
        m.insert("name".to_string(), self.name.to_json());
        m.insert("pts".to_string(), self.pts.to_json());
        m.to_json()
    }
}

fn make_data () -> Json {
    let sub_teams = vec![ Team { name: "Jiangsu Sainty".to_string(),
                             pts: 43u16 },
                      Team { name: "Beijing Guoan".to_string(),
                             pts: 27u16 },
                      Team { name: "Guangzhou Evergrand".to_string(),
                             pts: 22u16 },
                      Team { name: "Shandong Luneng".to_string(),
                             pts: 12u16 } ];

    let team = (Team { name: "Main Team".to_string(),
                       pts: 123u16 },
                sub_teams);
    team.to_json()
}

/// the handler
fn hello_world(_: &mut Request) -> IronResult<Response> {
    let mut resp = Response::new();

    let data = make_data();
    resp.set_mut(Template::new("array", data)).set_mut(status::Ok);
    Ok(resp)
}

fn main() {
    env_logger::init().unwrap();

    let mut chain = Chain::new(hello_world);
    chain.link_after(HandlebarsEngine::new("./examples/templates/", ".hbs"));
    println!("Server running at http://localhost:3000/");
    Iron::new(chain).http("localhost:3000").unwrap();
}

<html>
  <head>
    <title>Array Test</title>
  </head>
  <body>
    Main: <b>{{[0].name}}</b>: {{[0].pts}}
    <ul>
    {{#each this.[1]}}
      <li class="{{#if @first}}champion{{/if}}">
      {{@index}}. <b>{{name}}</b>: {{pts}} -- {{this}}
      </li>
    {{/each}}
    </ul>
    {{this.[1]}} <- output correct json
  </body>
</html>

The output will have all nulls for the sub-teams, even though it will print four lines with all null, so it is iterating over the right thing. More simple tests of array iteration seem to work, so I suspect something about the complexity of the json being passed is breaking things.

Accessing the sub-team array as just [1] also doesn't work.

There is a problem with the examples for watching templates https://github.com/sunng87/handlebars-iron/blob/master/examples/watch_server.rs .

no method named `watch` found for type `std::sync::Arc<hbs::HandlebarsEngine>` in the current scope

I want to be able to access the current request (in particular the extensions field) from within the template helpers I registered. The end goal is to make url_for from iron-router available in templates.

I realize that this is extremely hard and I'm not sure if handlebars-iron is even supposed to solve it. Flask solves the general problem by adding threadlocals everywhere, but I don't think that's the way to go for a framework and language where performance, control and data flow is more explicit than elsewhere.

Why?

The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback, and has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion in the Rust standard distribution and other project using dual MIT/Apache.

How?

To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright) and then add the following to your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2015 t developers
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>,
// at your option. All files in the project carrying such
// notice may not be copied, modified, or distributed except
// according to those terms.

And don't forget to update the license metadata in your Cargo.toml!

Contributor checkoff

• [x] @sunng87
• [x] @untitaker
• [ ] @viraptor
• [x] @cydrobolt
• [ ] @AlexTalker
• [x] @mvdnes
• [ ] @golddranks
• [x] @leodasvacas