[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:

          <div class="reveal">
            <div class="slides">
              <div id="footer">

              <a id="index" href="/"> <img src="/img/home.png" /> </a>
                <div id="slide-number"> </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>

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


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 


(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 &gt; 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 



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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.