Skip to content
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.

Sign up for GitHub

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

Jump to bottom

end of expression #2

Closed
ConnyOnny opened this issue Oct 9, 2016 · 5 comments
Closed

end of expression #2

ConnyOnny opened this issue Oct 9, 2016 · 5 comments

Comments

@ConnyOnny
Copy link

Currently ructe, inspired by twirl, uses a special character (@) to signal the start of an expression, but nothing special to signal the end of an expression. This is very nice when writing simple expressions surrounded by whitespace, tags, or anything else that doesn't look like a part of an expression, but it requires ructe to know the syntax of valid rust expressions and it is problematic if an expression should be immediately followed by something that looks like an expressions.

Should support for an optional — or required — end-of-expression marker be added? Maybe something like {=expression}? Otherwise, the expression parser will need to be improved. If I do and an end-of-expression marker, it will change the syntax of valid templates, so it should probably be decided one way or the other as soon as possible.

How about @…\n for simple stuff and @{…} for more complicated stuff (where … could contain new lines only in the latter case)?
@ConnyOnny
Copy link
Author

ConnyOnny commented Oct 9, 2016 •
edited
Loading

An alternative not using whitespace and looking familiar to many people would be this:
<?rct … ?>

A short hand to echo directly:
<?= … ?>
or in our case, as we don't have #1 yet:
<?=(…) … ?> where the former … specifies the context. This could then be made optional in a future version.

For the file beginning, it could be obligatory to start with the exact sequence "<?rct", because we anyway always need a header and in that way a file identification tool can quickly and reliably identify ructe files.

Example:

<?rct
use models::blog::{Entry, Comment};

template!<HTML>(entry: &Entry, comments: &[Comment]);
// or something else than "template!", maybe "arguments!"
// I like the "!" because it behaves much like a macro
// the <HTML> is necessary to solve #1 generically
?>
<!doctype html>
<html>
  <head>
    <title><?=(HTML)entry.title?> - my blog</title>
  </head>
  <body>
    <h1><?rct echo!<HTML>(entry.title) ?></h1>
    <?rct unsafe { echo_raw!(entry.content) } ?>
    <?rct for comment in comments.iter() { ?>
      <h2>Comment by <?=(HTML)comment.author?></h2>
      <?rct unsafe { echo_raw!(comment.content) } // I like how we have to use `unsafe` at this *really* unsafe spot. ?>
    <?rct } ?>
  </body>
</html>

Advantages

  • familiarity to anybody who has used PHP (which is practically anybody who has ever done anything in the web)
  • identifying a ructe file programmatically would be easy
  • template, echo and echo_raw could probably actually be implemented as rust macros
  • more visible separation between HTML and Rust code
  • doesn't give semantics to whitespace
  • easy parsing
  • control flow constructs (e.g. for) are just taken from Rust itself, and therefore are no surprise to anyone

Disadvantages

  • more verbose (or is that an advantage?)
  • breaks compatibility (which is fine because ructe is pre-1.0)
  • might remind people of PHP 😉
  • something I don't see right now, because it's my suggestion

@kaj
Copy link
Owner

kaj commented Oct 9, 2016

This syntax is also very similar to jsp, so I have considered it. Part of why I didn't choose it is the verbosity and part is that twirl just fees more natural and ergonomic, so I used that syntax. However, twirls superiority over jsp might be entirely independent of the syntax.

I have to think about this some more, so let's use this PR as a general discussion thread about syntax in general and expression syntax in particular for ructe.

@kaj
Copy link
Owner

kaj commented Oct 11, 2016

A related thing: I think there is a value in limiting the rust code that can be included in a template. It may be that I have just seen (and written, I have to admit) way to much java code embedded directly into .jsp files, and maybe developers of today would have better discipline, but I think @if ... and @for ... is about enough.

Also, not allowing arbitrary whitespace (i.e. newlines) in expressions may be a way to remind template authors to keep expressions reasonably short. If a more complex expression is needed, maybe that should be in a helper method?

@kaj
Copy link
Owner

kaj commented Jun 23, 2017

I have been testing and using ructe for a while in some projects by now, and I think the basic syntax is nice to work with. A template engine based on a more jsp- or php-like syntax could be created, but that would be another project.

So I'll just close this issue now. Thank you for the discussion, @ConnyOnny !

@kaj kaj closed this as completed Jun 23, 2017
@kornelski kornelski mentioned this issue Jun 18, 2018
Closed
@Aunmag
Copy link

Aunmag commented Dec 2, 2019

We could use rocker-like eval expressions:

-- @(file_name).sql
SELECT * FROM @(schema).@(table);

This was referenced Dec 4, 2019
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kaj @ConnyOnny @Aunmag