Settle on a mime type for the templates when embedded in html as a script

[mwawrusch]

It is common practice to embed templates in html as script like so :

<script id="foo" type="text/x-plates-tmpl"> Here goes all your template text..... The plates team should decide on a mime type (text/x-plates-tmpl or text/x-plates comes to mind) and put that, including the example from issue 7) on the readme. Make it simple for casual users to start without having to think.

[heapwolf]

Goes against philosophy of the library. The libraries principal motivation is Separation of Concerns. Javascript has no business being inside html, and unless you are writing a library like jQuery or mootools, html should usually stay out of the Javascript.

[mwawrusch]

I get your philosophy, storing html template code in javascript, from a practical perspective this unfortunately does not work for me. And just to clarify, I was not talking about putting Javascript into the html, but the template html as part of a script tag, which is extremely useful for client side only apps.
In any case thanks for your time in writing this library. That's definitely appreciated.

[tblobaum]

@hij1nx how do you load up a large template?

[heapwolf]

How do you define large? ...my primary inhibition about using a script tag to hide html fragments is that it feels over engineered. using a script tag to hide templates is really only useful when your template consists of non-standard html and will potentially produce parser errors. If you have a large template to conceal, you may consider the following, it would be much simpler...

<style>
  .templates { display: none }
</style>

<!-- ... -->

<div class="templates">
  <div id="template1">...</div>
  <span id="template2">...</span>
</div>

<!-- ... -->

[mwawrusch]

Large in my case is multiple templates, at least hundred lines of html, probably more, split in > 10 templates, which are written in haml (that backend is still in ruby) and emitted as html. Benefit for writing it in haml (as standard html, no template preprocessing) is that the html is hundred percent correct and no bugs can creep in.

And two reasons for wrapping it in a script tag instead of the way you described:

1. No parsing takes place. It seems to me that parsing it twice would defeat one selling argument of plate, that it is super fast.
2. Potential side effects with having the templates in the dom tree and jquery plugins inadvertently interacting with them. I might be overcautious here, but if something like this happens it takes ages to debug.

[heapwolf]

sounds crazy ;o)

Large in my case is multiple templates, at least hundred lines of html

Should never happen on the client (in an ideal world), so reflow, dom-tree etc are moot.

which are written in haml (that backend is still in ruby)

You are definitely in the 20 of the 80/20. in fact i'd say you're in the 5-10. I see what you mean about the haml creating correct html, but imho haml looks like ascii vomit ;o) and i'd personally rather keep the extra layer out of my stack.

To address your points... 1) this is a client-side domain-specific problem. templates as large as your talking about on the client side are a design deficiency. even if you hide it from the dom-tree initially, parsing an html fragment of this size and incurring the costs associated with injecting it back into the document (reflow etc) will result in a slow user experience [as im guessing that this would happen more than once since we're talking about templating].

2. this is a good point, having something in the dom-tree already, there is the opportunity for a template or a part of it to accidentally get clobbered by a selector or unwitting script. I'm not sure this argument, or the later justify introducing potentially more complex requirements such as mime types and script tags.

conversely, there is no code requirement from plates to use a script tag to hide a template. So even though i don't think it should be the default convention, it's still perfectly valid to use it.

I think this is possibly a subject that could be covered in the docs. If so, I think we could present both options.

[mwawrusch]

Well, I wish I would be in the 1%, the 20% to 2% is really the bad spot in life :)

Regarding haml, I actually prefer the jade syntax, but it's not worth changing the code for me. And I think it's like coffeescript vs javascript - you either love it or hate it :)

And the templates itself are rather small, but there are many of them, something like 20 templates with 5 - 10 lines of html. Most of them are rarely invoked, so speed is not an issue (I always test on a 5 year old windows machine - if it runs there it will everywhere)

Fully agree with your last 2 paragraphs.

[heapwolf]

Do you want to draft something/make a pull request on the readme.md regarding usage/best practice surrounding hiding template fragments? maybe starting with the simple html case and progressively enhancing to the script-tag case? You appear to understand the problem-domain well.

[mwawrusch]

Love to. I'll write something will send pull on Saturday.

[mwawrusch]

I created a wiki instead of pulling readme, it is easier for me to work with it. I"ll update the page a bit tomorrow, fill in the missing code pieces and add a second page regarding how to name your classes etc.

Here is the link for the first one, corrections are welcome, I am not a native speaker so there will be grammatical errors:
https://github.com/flatiron/plates/wiki/Client-Side-Plating

[heapwolf]

woah, you rock man.

[tblobaum]

Hey, that looks like what i needed too. You can use native code to grab those nodes too. I'm sure a best practice will emerge for defining and grabbing templates that aren't in script tags

function OuterHTML(element) {
    var container = document.createElement("div");
    container.appendChild(element.cloneNode(true));
    return container.innerHTML;
}

[mwawrusch]

Thanks guys. @tblobaum I'll add your code with the next iteration to the wiki.