3

Due to some library incompatibilities, I'm not able to use both Pandoc and Heist in the same application. As such, I decided to go with Markdown.JS to handle converting from Markdown format data into HTML in the client's browser. This could have some nice extra benefits in the long run, but in the short run, it is just because Pandoc depends on Blaze-HTML 0.4 and Heist depends on Blaze-HTML 0.5.

So, in a weblog-like application, I have a template that is used to fill out each entry, but then the content of each entry needs to get converted into HTML after the page has been loaded. So, I created a template that looks like this:

<h2> <a href="wiki/${target}"><entryTitle /></a> </h2>
<p class="entryDate"> <entryDate /> </p>
<div id="body_${entryDate}">
<entryBody />
</div>

<script type="text/javascript">
renderDiv("body_" + <entryDate />)
</script>

Unfortunately, the renderDiv call ultimately renders like this:

<script type='text/javascript'>
renderDiv("body_" + <entryDate />)
</script>

I have also tried using the string-embedded form (like I did for the div id in the template):

<script type="text/javascript">
renderDiv("body_${entryDate}")
</script>

Again, it renders verbatim.

How do I convince Heist to splice in the entryDate inside of the javascript?

Alternately, I'm using Prototype.JS as a Javascript library. Is there a way for me to put the script inside of the div and call the script basically with "self"?

<div id="body_${entryDate}">
<entryBody />
<script type="text/javascript">
renderDiv($(self))
</script>
</div>
Savanni D'Gerinel
  • 2,379
  • 17
  • 27

1 Answers1

2

Heist intentionally does not do splice substitution inside script tags, because splicing is done on DOM elements, and the contents of a script tag are plain text, not a DOM. We do it this way because if we did what you want, the parser would not be able to tell whether a '<' character represented the binary less than operator, or the start of a tag. user1891025's suggestion of generating a complete script tag is one way to do it.

However a dependency conflict between Heist and Pandoc shouldn't prevent you from using our built-in markdown splice. We don't actually link the Pandoc library. We only depend on the pandoc executable program. So all you have to do to make it work is build pandoc from a clean repository (or use a build sandbox), put the pandoc binary in your path, and then build Heist from another clean repository/sandbox. Then you won't have to worry about any of this javascript stuff.

If you still want to use javascript for this or something else, I would recommend that you not generate javascript from Heist. Heist was designed for HTML generation, not javascript generation. I prefer to put all my javascript in standalone .js files. Then you can conveniently load them using this splice from the snap-extras library.

To answer your last question, you can call a div like that with renderDiv(this).

mightybyte
  • 7,282
  • 3
  • 23
  • 39
  • Thanks. I'm trying to go with pandocBS directly because I'm loading the Markdown content from another file and putting the formatted version into the template. markdownSplice seems to require that the markdown content already be in my template, which it is not. Text.XML.Expat.Tree.parse' does not seem to produce an XML node that con be easily converted into a Text.XmlHtml. So, I'm using Text.XmlHtml.parseXML directly but having trouble with the "typographically correct" flag in pandocBS producing character codes that I can't handle yet. – Savanni D'Gerinel Dec 28 '12 at 17:26
  • No, the markdown splice doesn't require that. Here's how we are using it in the Snap website. https://github.com/snapframework/snap-website/blob/master/snaplets/heist/templates/faq.tpl – mightybyte Jan 02 '13 at 19:49
  • @mightybyte , how would you recommend generating the javascript for the example in this question? I have a similar problem where I want to set an environment variable to differentiate between production and development and the JS i render needs to utilize the it. – jvans Sep 16 '15 at 01:59
  • @jvans [jmacro](http://hackage.haskell.org/package/jmacro) is nice for that kind of thing. – mightybyte Sep 16 '15 at 14:53