-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Templating Engine Support (as Middleware, ideally) #125
Comments
rust-mustache is pretty decent. I'm not sure about making this middleware. Do mean create a new piece of middleware that acts as the templating engine? I'm familiar with how Express does this for NodeJs. The developer configures Express to pass through res.render() invocations to the templating engine. The developer also supplies template director(y|ies). Do you plan to create something similar? |
This is tricky, because we'd like the method to be implemented on This are good thoughts to be having, but I'm not sure what the answer is. |
I just realized that Mixins would make Middleware an ideal way to provide a replaceable templating engine. Sorry I'm a little slow on the uptake. Perhaps, we could establish a convention that a particular Alloy entry (maybe something like a Vec of Path objects) contains the directories for whatever template engine Middleware is used. There could be a Hashmap in Alloy for per-engine app-wide configuration settings. A third part of the convention could be that a piece of middleware acting as the render engine would provide a res.render() method via Mixins. How does that strike your fancy? |
I think it's cleaner to just provide a This is solvable by placing a second Maybe the best way would be to add a global-configuration Alloy on each Iron instance - then provide a &-reference to the app in both request and response? This is fast but also quite convenient, and could in fact be made memory efficient by storing the global Alloy behind an Arc, so it is not cloned for each request. |
Yes! That's essentially what express does with It seems like there may be other app-wide configuration needs that may come along anyway -- there should a simple app-wide in memory data-store ready to go. |
I'm only concerned that adding a reference to the app in |
Ugh -- that would suck. Hmmm, maybe we could check for an environmental variable (IRON_VIEWS) and fallback to a default directory for templates (./views). I'm not sure if I'm in love with this idea, but it should prevent any unsafe could or references back to Iron in res or req... I saw that repo. I'm super excited to play with that. |
There's way too much of I'd really rather not fall back to an environment variable. Maybe, instead of a global persistent reference to Iron, we could just have a global persistent reference to some sort of global preferences object that only coincidentally happens to be stored on I think that we'll find, however, that there may be a need for a general-purpose Alloy-like structure on Response. |
Yeah, relying only on environment variables is wrong. |
I think there needs to be a dedicated way to immutably access shared global configuration. More thoughts to come. |
I think the solution is to include a |
I think this is the most ergonomic solution. Would it make any difference if the config is accessed in Response or Request? It feels wrong to provide the same information in two places, but I can't think of any particular problems with this idea. |
I think providing access to config in both places is perfectly fine. |
The configuration problem is mostly solved through the |
I don't know if this question is relevant, just curious if it's possible to compile a view as part of the build process. For example there is play! framework for Scala, where views are normal scala files, statically checked and compiled by the scala compiler (https://playframework.com/documentation/2.3.x/ScalaTemplates). I wonder if it's possible to do the same in Rust. |
You can definitely do this with a syntax extension, or even without one if you are willing to lose a bit of expressiveness. However, I think that's probably the domain of a templating engine, not this middleware. |
it could be interesting to look at the way Nickel has implemented mustache support |
@aochagavia They have done much of the work that we'd like to do, but I'd much rather be templating engine agnostic and support a richer interface - notably nickels |
as someone was noting for scala, in cppcms , a webframework in C++ (so in the same segment of "compiled language") the use template file , that get compiles into C++ basically the idea is that your template file is converted into a C++ class + a name , which is then added to a hashmap, then in your "controller" methods you just do
content_structure being a plain struct, with the data you want to render in your template. The advantage I see to this approach is
http://cppcms.com/wikipp/en/page/cppcms_1x_templates_gen |
@allan-simon sounds like this would really put us ahead of the node / ruby / python community by really leveraging all the best parts of rustc. |
Agreed. There could be some really cool work to be done in making a crazy syntax extensions for creating templates. |
I've finished a side project of mine these last days, and I've started today to take a look at syntax extensions, I will soon create a "toy" repository on my github to keep track on my progress on comprehension of "how to create complex syntax extensions" , so that at the end I could use to have a tutorial on how the machinery work, so that we don’t end up with an unmaintainable extension. I will keep you updated on my progress for this, though I think it's going to take me at least a week or two before getting a "beginning of proof of concept", but things will get faster after a good grasp on this. |
@allan-simon I also just recently started learning about syntax extensions. If you want an example of a (hopefully) well written one: https://github.com/reem/stainless |
@reem Perfect it will help a lot. |
Hello, just to keeps you updated, using your stainless extension and brain_fuck macro, I've started a toy html template extension and now i'm able to generate function to output html and to mix rust code in it https://bpaste.net/show/62c46adedcb2 right now I have 2 tags
other things are treated as html and added to the output buffer returned by string Right now I'm still making myself clear about what i want, and I will tell you when I got something that reflect my idea of the templating engine I want, so that we can start discussing about making change on it |
@allan-simon I think it would probably be best to adopt an existing templating standard and possibly just make changes to it, rather than starting from scratch. The most ideal situation is that I can create |
actually as said, I'm basing the syntax/concept fully on the one of the "cppcms" framework, (which I think was also based on an existing one, as vim was able to put a nice syntaxic coloration) as I think it's closer to what I'm doing (i.e template transformed into native code at compilation time) and yup as you said, the goal is to have the same garanty in the template as we have in rust, i.e if it compiles then you're sure it works (i.e syntax checking / type checking etc.) |
Hi, I have talked with @reem in IRC but also want to update here. I have been working on a handlebars template engine for rust and I'm going to create an iron middleware for integration. By far, the handlebars-rust project is almost finished and should support most of handlebars features, helper customization and template inheritance. I'm now working on the middleware. Since it's still difficult to compile iron against rust nightly, I may still need several days for it. As discussed with @reem, we will create a new |
To answer some questions above, handlebars is a widely used template syntax created by Yokuda Hatz (yes, it's who made cargo also) originally in javascript. In handlebars-rust, there is a tricky point that you have to make the data implements |
Just a note, but its Yehuda Katz, aka wycats. :) |
Oh, sorry for wycats. |
The middleware handlebars-iron is done and available from crates.io |
I think this can be closed since handlebars-iron seems to work fairly well. |
mustache is probably the only thing worth supporting right now
The text was updated successfully, but these errors were encountered: