badmanners/maud
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
maud/maud_macros/tests/basic_syntax.rs

135 lines
3.4 KiB
Rust
Raw Normal View History

Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
#![feature(plugin)]
#![plugin(maud_macros)]
extern crate maud;
#[test]
fn literals() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!("du\tcks" "-23" "3.14\n" "geese").into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "du\tcks-233.14\ngeese");
}
#[test]
fn escaping() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!("<flim&flam>").into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "&lt;flim&amp;flam&gt;");
}
#[test]
fn semicolons() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html! {
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
"one";
"two";
"three";
;;;;;;;;;;;;;;;;;;;;;;;;
"four";
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
}.into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "onetwothreefour");
}
#[test]
fn blocks() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html! {
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
"hello"
{
" ducks" " geese"
}
" swans"
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
}.into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "hello ducks geese swans");
}
#[test]
fn simple_elements() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { b { "pickle" } "barrel" i { "kumquat" } }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "<p><b>pickle</b>barrel<i>kumquat</i></p>");
}
#[test]
fn nesting_elements() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(html body div p sup "butts").into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "<html><body><div><p><sup>butts</sup></p></div></body></html>");
}
#[test]
fn empty_elements() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!("pinkie" br/ "pie").into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "pinkie<br>pie");
}
#[test]
fn simple_attributes() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html! {
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
link rel="stylesheet" href="styles.css"/
section id="midriff" {
p class="hotpink" "Hello!"
}
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
}.into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, concat!(
r#"<link rel="stylesheet" href="styles.css">"#,
r#"<section id="midriff"><p class="hotpink">Hello!</p></section>"#));
}
#[test]
fn empty_attributes() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(div readonly? input type="checkbox" checked? /).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<div readonly><input type="checkbox" checked></div>"#);
}
#[test]
fn colons_in_names() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(pon-pon:controls-alpha a on:click="yay()" "Yay!").into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, concat!(
r#"<pon-pon:controls-alpha>"#,
r#"<a on:click="yay()">Yay!</a>"#,
r#"</pon-pon:controls-alpha>"#));
}
#[test]
fn hyphens_in_element_names() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(custom-element {}).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "<custom-element></custom-element>");
}
#[test]
fn hyphens_in_attribute_names() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(this sentence-is="false" of-course? {}).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<this sentence-is="false" of-course></this>"#);
}
#[test]
fn class_shorthand() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { "Hi, " span.name { "Lyra" } "!" }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<p>Hi, <span class="name">Lyra</span>!</p>"#);
}
#[test]
fn class_shorthand_with_space() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { "Hi, " span .name { "Lyra" } "!" }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<p>Hi, <span class="name">Lyra</span>!</p>"#);
}
#[test]
fn classes_shorthand() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { "Hi, " span.name.here { "Lyra" } "!" }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<p>Hi, <span class="name here">Lyra</span>!</p>"#);
}
Allow names with multiple hyphens in a row Fixes #40
2016-08-07 20:39:31 +12:00
#[test]
fn hyphens_in_class_names() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p.rocks-these.are--my--rocks "yes").into_string();
Allow names with multiple hyphens in a row Fixes #40
2016-08-07 20:39:31 +12:00
assert_eq!(s, r#"<p class="rocks-these are--my--rocks">yes</p>"#);
}
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
#[test]
fn ids_shorthand() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { "Hi, " span#thing { "Lyra" } "!" }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, r#"<p>Hi, <span id="thing">Lyra</span>!</p>"#);
}
#[test]
fn classes_attrs_ids_mixed_up() {
Rewrite everything to use Strings instead of writers After fiddling around with zero-allocation solutions, I concluded that all non-allocating approaches are too annoying to work with in realistic code. Using closures leads to yak-shaving with lifetimes; and because Iron needs to take ownership of the response body we often end up cloning the input data anyway. Removing this constraint has let me simplify the entire system, removing a net 300 lines from the library. The `html!` macro no longer takes a writer, and instead returns a `PreEscaped<String>`. This means that the result of an `html!` can be spliced directly into another `html!`, removing the need for the `impl Template` rigmarole. To rub it in, benchmarks show the new code is in fact *faster* than it was before. How lovely.
2016-09-23 19:22:22 +12:00
let s = html!(p { "Hi, " span.name.here lang="en" #thing { "Lyra" } "!" }).into_string();
Refactor tests Closes #39
2016-07-31 21:34:46 +12:00
assert_eq!(s, "<p>Hi, <span lang=\"en\" class=\"name here\" id=\"thing\">Lyra</span>!</p>");
}
Reference in a new issue Copy permalink