JS templating:<br>Mustache.js is pretty darn popular, as are its clones. dust.js is worth a look, as it is already ready for the kind of &quot;zippy&quot; stuff that 0mq can do... there&#39;s a lot of good competition in the space right now, so people are actually competing on performance, usability and features :)<br>
<br>A use case:<br>I had previously done some work with implementing a tangle.js (<a href="http://worrydream.com/Tangle/">http://worrydream.com/Tangle/</a>) markdown extension (<a href="https://github.com/bollwyvl/TangleDown">https://github.com/bollwyvl/TangleDown</a>). I ended up doing all the parsing in py, which was not A Good Idea, as it turns out... whereas doing the heavy duty constrain solving to get bidirectional stuff didn&#39;t work very well in JS. Bad choice of tools, i guess.<br>
<br>I&#39;d like to replace (to the extent possible) all of the javascript exec&#39;d stuff with bindings to kernel values, while keeping all of the constraint logic in the backend: thus, I&#39;d like user modifications to the front end to be bound into execution requests to re-update the front-end without rerendering the whole template.<br>
<br>This goes a little beyond what you are proposing, but there may be some common ground.<br><br>A low-risk implementation:<br>Based on the stuff i am working on right now, it could look something like this:<br>- store the templated markdown in a degenerate code cell:<br>
<br>    %load_ext tmplmd<br>    display(TemplatedMarkdown(&quot;&quot;), context={})<br><br>- enable an input widget, something being discussed on the custom cells thread... it could be hacked in already with an output handler... but i digress. Anyhow, somehow show a UI that generates normal python code... in this case, you&#39;d update the arguments to TemplatedMarkdown, so it becomes:<br>
<br>    display(TemplatedMarkdown(&quot;&quot;&quot;<br>    # {{title}}<br><br>    {{ for result in results }}<br>      - {{ result }}<br>    {{ endfor }}&quot;&quot;&quot;,<br>    context=dict(title=foo, results=[bar, baz]))<br>
<br>- on the python side (where you use load_ipython_extension, see brian&#39;s example in <a href="https://github.com/ipython/jsplugins/blob/master/d3graph/d3graph.py">https://github.com/ipython/jsplugins/blob/master/d3graph/d3graph.py</a>) implement a formatter that returns something like:<br>
    {<br>        &quot;template&quot;: &lt;the template&gt;,<br>        &quot;context&quot;: {<br>            &quot;title&quot;: foo,<br>            &quot;results&quot;: [&quot;foo&quot;, &quot;bar&quot;]<br>        },<br>
        &quot;handler&quot;: &quot;tmplmd&quot;<br>    }<br>- and then let the client take over to actually render it.<br><br>the ipynb just knows there is some code, and the text would stay mostly human readable and editable for other consumers.<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 15, 2012 at 3:52 PM, Matthias BUSSONNIER <span dir="ltr">&lt;<a href="mailto:bussonniermatthias@gmail.com" target="_blank">bussonniermatthias@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 15 déc. 2012 à 21:31, Carl Smith a écrit :<br>
<div class="im"><br>
&gt; I&#39;m not sure if you guys have seen this, but there&#39;s a Python Markdown<br>
&gt; project that might be useful here.<br>
<br>
</div>And this MD implementation is what nbconvert/nbviewer uses.<br>
<br>
Thanks for pointing this though.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Matthias<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br></div>