This is the template.
The basics
Include.js Core Templates plugin support simple yet comprehensive template language, based on JavaScript inlining. You can use two templating tag styles - "mustache" and "ASP-style".
Here's a list of Core Templates tags:
{{ this.core_tags( $1, tags ) }}
Yep, that's it. By the way, the table above is generated with these tags, and is the test. Please, take a look inside html/main.html
You include template with name 'html', and it gets automatically compiled to JS function. You can call this function in your code with context object, and it will evaluate template with its embeeded JS in the given context, and return text. That's simple. Like this:
var html = _.html( { a: 5, b: "dsdsd" } );
Or, if you're using jQuery, you can do this:
_.html.renderTo( $('#holder'), { a: 5, b: "dsdsd" } ).click( function(){ alert('Yahooo!');});
Or this:
$('#holder').render( _.html, { a: 5, b: "dsdsd" } ).click( function(){ alert('Yahooo!');});
And template will be rendered to #holder tag, erasing all previously existing inner HTML. And that's it.
Oh, year, there are third tag, which represent the most interesting feature of Core Templates. Sections.
Sections
Section - it's just the named subtemplate declaration you can put in you document, and use it from main section, or JS module. Or from the other section. Sections allow you to split large HTML document to the number of reusable parts. How it looks like? Well, have you opened this template (html/main.html)? :) It's good example.
Defining section is easy.
{{ this.core_tags( $1, sections ) }}
Sections are translated to template functions in _.html namespace. For example, table with tags above can be accessible as _.html.core_tags from .js file, or - as this.core_tags from inside of this template.
When you want to directly inline section in the template, you need to pass parameters to this function call. First parameter is context, and it can be referred as $1. In addition, you can pass secons $2 and third $3 parameters.
Sections are extremily useful feature. Some use cases:
- Fight the complexity of deep HTML trees. In case if HTML tree becomes hard to understand, you can take parts out of it and move them to the sections.
- Similar patterns in the document. Move them to the sections, and you will remove the pain.
Rationale
{{ this.why_such_templates( $1 ) }}
{-- core_tags --}
{- for( var i in $2 ){-}
<% var tag = $2[ i ]; %>
{{ tag.desc }} |
| <%= tag.mustache %> |
| {{ $2[ i ].asp }} |
|
{-}-}
{-- why_such_templates --}
Now let me explain, why templates looks like they looks:
- I believe that there's no real reason to introduce templating DSLs, while we have JS already.
- JS have necessary control structures.
- JS is more powerful, than any of templating DSLs. With emedded JS capabilities you're sure, that you can do _everything_ you need.
- Templates with embedded JS can be easily compiled to JS, and they are FAST
- And there's one important thing - you already know and unrestand JS, and there's nothing to learn.
- You might have different point of view - and that's fine. I suspected that, and specially designed the system in the way, allowing you to easily extend templating system. I mean, it's _really_ easy.
- All 'smart' content modules are handled through plug-ins
- Core Templates itself is the plugin.
- Plugins can call each other
- You can translate your favorite template syntax to Core Templates one, and pass the result to 'html' plugin, to do the rest of magic.
- ???
- PROFIT! Actually, this is the major reason for Core Templates to be minimalistic. It's degined to be the basis for more complicated templating DSLs.
- Why I's using so strange JS-inline tags in 'mustache' case? It's so complicated to count JS backets when inserting if-s and for-s...
- Because I hate counting brackets. You don't need to do it with mustache style.
- The right way - to count {{ block }} and {{end}} patterns. Its so easy, that when you get used to it, you will not need DSLs, cause embedded JS will looks just fine.