|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] using cow
On 23 Dec 2013, at 12:31, Anil Madhavapeddy wrote:
> You can't insert the string verbatim, as the type of the $$ must be a
> Cow.Xml.t. The whole point of $str:$ is to take care of escaping.
>
> However, you should be able to just parse the template fragment into
> Cow.Xml.t and insert it as such.
no-- the template fragment encloses the slides content, and as cow (quite
reasonably) doesn't allow unbalanced expressions i can't break down the
<body>...</body> chunk further, viz:
"""
<body>
<div class="reveal">
<div class="slides">
$slides$
<div id="footer">
<a id="index" href="/"> <img src="/img/home.png" /> </a>
<div id="slide-number"> </div>
</div>
</div>
</div>
<script src="/reveal-2.4.0/lib/js/head.min.js"> </script>
<script src="/reveal-2.4.0/js/reveal.min.js"> </script>
<script src="/reveal-2.4.0/js/init.js"> </script>
</body>
"""
i could do something grim with printf and friends, avoid cow completely, and
just read chunks from files like i did with the old version of decks, but i was
hoping to avoid that...
> I'm guessing it doesn't parse because of...
a concrete example-- in the cam13/index.html there're slides like:
"""
<section data-markdown>
<script type="text/template">
## A Minimal Kernel
A simple OCaml program like this is easy to run without Unix.
let rec qsort = function
| [] -> []
| pivot :: rest ->
let is_less x = x < pivot in
let left, right = List.partition is_less rest in
qsort left @ [pivot] @ qsort right
**Why?**
</script>
</section>
"""
this can't be parsed by cow because of (among other things that i can fix
easily enough, notably data-markdown being an empty attribute -- fix is to
write data-markdown="" instead -- for which i believe i saw an issue already
raised) the ">" characters in the ocaml example.
> Alternatively, you could make it valid XHTML by wrapping it in a CDATA.
>
> ...The latter is probably the best solution, since we serve the MIME type
> as XHTML anyway.
yes -- CDATA is the obvious thing i was missing. probably the most workable fix
is to wrap the code fragments in
<pre><code><![CDATA[
...
]]></code></pre>
(the manual pre/code elements are needed because the ``` code block delimiter
doesn't escape the contents from the XML parser, but applying it with the CDATA
delimiters causes the > to render (literally) as > etc.)
thought: given the use and abuse to which xml/html are put though (or, if you
prefer, the flexibility which they provide), having some kind of [`Raw of
string] might be useful. kind of like a CDATA but which doesn't leave any tag
in the xml when rendered to a string (ie. the element tag never gets to the
browser).
--
Cheers,
R.
This message and any attachment are intended solely for the addressee and may
contain confidential information. If you have received this message in error,
please send it back to me, and immediately delete it. Please do not use, copy
or disclose the information contained in this message or in any attachment.
Any views or opinions expressed by the author of this email do not necessarily
reflect the views of the University of Nottingham.
This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you
are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |