Closed EliAndrewC closed 10 years ago
I'm fine with it
On Mon, Apr 14, 2014 at 11:28 AM, Eli Courtwright notifications@github.comwrote:
We're currently using the following non-default Jinja tokens so as to not conflict with angular:
$(% tokens for block statements %)$ $(( tokens_for_values ))$
I've been doing some more Jinja work recently for building a small website for QA, and I'm finding that I really like the tokens for values and really hate the tokens for block statements.
Unless anyone strongly objects, I'm going to change the tokens for block statements to look like this:
((% tokens for block statements %))
After playing around with a lot of different values, that's the one I like the most. Any objections?
— Reply to this email directly or view it on GitHubhttps://github.com/appliedsec/sideboard/issues/53 .
reopening this because the create plugin template should use these new values
Good catch, that was something I only noticed later while doing the Python 3 compatibility stuff, and the fix is part of that pull request, which I plan to merge this weekend. Here's the current template file in that not-yet-merged feature branch:
<!doctype html>
<html>
<head><title>$(( plugin ))$ skeleton page</title></head>
<body>
((% if header %))
<h1>Hello $(( plugin ))$ developer!</h1>
((% endif %))
</body>
</html>
We're currently using the following non-default Jinja tokens so as to not conflict with angular:
I've been doing some more Jinja work recently for building a small website for QA, and I'm finding that I really like the tokens for values and really hate the tokens for block statements.
Unless anyone strongly objects, I'm going to change the tokens for block statements to look like this:
After playing around with a lot of different values, that's the one I like the most. Any objections?