Besides going against my first rule, this approach is conceptually very weird, at least to me. You have a widget for the opening tag but you must close it manually, in a way that’s completely opaque to someone who looks at the code. I think I prefer turning form_for(form, action, options, fun) into a macro which calls fun.(form) at compile time.
The main problem is that form can be anything that implements a protocol, so it would have to be converted into %FormData{} by all inner widgets. That’s very inefficient (although still the right choice if we want to optimize for bandwidth at all costs!).
The problem is that with my model (respecting the first rule) you can’t precompute the conversion to %FormData{} at runtime! So you’d have to perform that conversion outside the template (this is a limitation of my apparoach I didn’t think of earlier…)
There might be a way out that avoids my rule, though (I’ll get very technical here). The semantics of variable rebinding and its scope is what got us into this mess. In an EEx template, we must respect rebinding semantics, which means an EEx template is compiled to a series of nested lists with blocks inside the lists, which is kinda messy to refactor automatically. For example, if you compile this template:
<%= a = 1 %>
<%= a %>
<%= a = 2 %>
<%= a %>
with the default phoenix engine, you get this:
{:safe,
[
(
tmp1 = [
(
tmp1 = [
(
tmp1 = [
(
tmp1 = ""
[
tmp1
| case(a = 1) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
]
)
| "\n"
]
[
tmp1
| case(a) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
]
)
| "\n"
]
[
tmp1
| case(a = 2) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
]
)
| "\n"
]
[
tmp1
| case(a) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
]
)
| "\n"
]}
(those not experienced in looking at printed macro output, remember that parentheses on their own lines are block delimiters in Elixir)
With my simplified semantics, without variable rebinding, I can compile the template into something like this (I’m cheating a little by removing the {:safe, ...} tuple, but you get the idea.
[
"",
[
case(a = 1) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
],
"\n",
[
case(a) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
],
"\n",
[
case(a = 2) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
],
"\n",
[
case(a) do
{:safe, data} ->
data
bin when is_binary(bin) ->
Plug.HTML.html_escape_to_iodata(bin)
other ->
Phoenix.HTML.Safe.to_iodata(other)
end
],
"\n"
]
You can see that I was able to optimize the template into a list where alternate elements are either static or dynamic. That is very hard to do with the default HTML template…
I’ve thought about trying to build lists as I walk the EEx file. The output of a EEx engine doesn’t need to be a quoted expression representing the template, which means I can thread a context as I parse the source and then try to output something sensible from the context, but so far I’ve been having troubles. No matter how you look at it, the output of an EEx template seems to require a deeply nested tree of blocks with many instances of variable rebinding.
This is a problem Elixir already has to solve when compiling to Erlang (there are no variable rebindings in Erlang). To compile to Erlang, Elixir uses something called Static Single Assignment, in which something like this:
a = 1
a = a + 1
a = a + 2
becomes:
_a@0 = 1
_a@1 = _a@0 + 2
_a@2 = _a@1 + 3
If we could replace the reassigned variables using Static Single Assignment, we could probably turn the AST inside out, and move all variable calculations outside the tree and collapse the tree into a simple flat list. I’ve been avoiding going that way, because that requires an intimate knowledge of the core elixir semantics (namely, it requires the programmer to know all places where variables can be bound). But besides that, I can’t see any way of simplifying the AST returned by the EEx engine and separating the static from the dynamic parts.
