More newlines issues

11 views
Skip to first unread message

Magnus Holm

unread,
Feb 20, 2010, 3:49:38 PM2/20/10
to guardians-o...@googlegroups.com
This newline stuff is still not sorted out:

I've changed :static a bit in e368a9a5. Earlier, [:static, "foo\nbar"] would be generated into _buf << "foo\nbar". This makes perfectly sense, but most
of the time a newline in the static actually means there's a newline in the template source too. Then you had to use [:static, "foo\nbar"], [:newline] in order to fix that. (Which also looks very funky when you use DynamicInliner).

After this commit, [:static, "foo\nbar"] will actually generate _buf << "foo[NEWLINE]bar", where [NEWLINE] is a a newline and not a backslash+n. I think this makes sense *most* of the time. This is how ERB, Mustache and Liquid all works, but there still might be a template engine which want to send a newline to the client which isn't a newline in the template source.

Haml for instance:
%div Some big, indented div here.
%p= raise 'Oh no!'

Could be generated into:
_buf = [] ; _buf << "<div>\n  Some big, indented div here.</div>\n<p>\n  " ;
_buf << (raise 'Oh no!) ; _buf << "\n</p>" ; _buf.join

However, if this is represented as [:static, "<div>\n  Some big, indented div here.\n</div>\n<p>\n  "], [:dynamic, "raise 'Oh no!"], [:static, "\n</p>"] it would today be compiled to:
_buf = [] ; _buf << "<div>
  Some big, indented div here.
</div>
<p>
  " ; _buf << (raise 'Oh no!) ; _buf << "
</p>" ; _buf.join

And thus the error will occour at line 5 instead of line 2.

Solutions that I can think of:

1. Introduce :static_singleline
Crappy name, but the idea is to have another type which behaves the way static behaved earlier. I don't really like to introduce more types at the moment though…

2. Introduce [:static, "foo\nbar", true]
We could make static take a second argument, which indicates that this static should behave like static behaved earlier. If we're going for this, it means that the signature has to change to "def on_static(str, single = false)", and we can't just change the signature all the time.

3. Do nothing, make people use [:dynamic, str.inspect] when it's needed
We could also don't do anything at all, since you could just turn such statics into [:dynamic, str.inspect] and it would work. (static is currently just another "syntax" for [:dynamic, str.inspect.gsub('\n', "\n")]). If you still want to do anything fancy with statics, you could use the new Temple::Utils.literal_string?(str) on dynamics to see if it's really a static. That's kinda hackish though.

For now, I think I'm going for 3. Mostly because I'm lazy though. I'd rather introduce static_singleline later.

Any thoughts or ideas?

// Magnus Holm
Reply all
Reply to author
Forward
0 new messages