Jump to content

Thoughts on this theoretical template language?

So I'm currently working on a personal project that I may very well end up releasing to the public as it nears completion. It is a web project (since that's what probably 90% of my development is), and part of it is going to be designing and implementing a nice template language. There are already a lot of options available in this area, but most of them have features that I personally don't feel are appropriate, particularly when the main purpose of a template language is to separate application logic from the output. I'm sure that if I spent longer looking then I may very well be able to find something that works well for my situation, but again, since this is a personally project, it's something that I want to create entirely independently.

 

So, with that out of the way, the focus of the language I am designing is to be relativly consise, while still maintaining readability. There's no be no things that I would consider "application logic", such as variable assignment, but rather just some basic control structures, and the ability to produce output. It will primarily be used in HTML, but it's also designed to be completely separate from the context it's used within, so that shouldn't have an impact on it's design.

 

I have written up a draft type template using just the very basics that I intend to implement, but before doing so, I decided to post it here and get a second opinion on it.

 

<!DOCTYPE html><html>    <head>        <title>{{ title }} | My Awesome Website</title>    </head>    <body>        <h1>{{ title }}</h1>        <nav>            {[ page in navigation ]}                {{ link.to(page) }}            {[ end ]}        </nav>         <ul class="articles">            {[ if articles | article in articles ]}                <li>{{ article.name }}</li>            {[ else ]}                <li class="error">No articles were found.</li>            {[ end ]}        </ul>         {{ copyright? }}    </body></html>

 

Hopefully it shouldn't need much, if any explanation, as it's intended to be easy to read. The basic idea is that anything within {{ }} tags will be evaluated, escaped and outputted, while anything within {[ ]} blocks will only be evaluated, allowing for control structures.

 

The line:

{{ copyright? }}

would be parsed to be equal to:

{[ if copyright ]}    {{ copyright }}{[ end ]}

 

If I've done even a half decent job on it, then that should be all the explanation that's needed to understand it. Please let me know if there's anything you think could be added or changed in order to make it more readable, and I'll certainly consider implementing them.

 

Thanks!

Link to post
Share on other sites

Ha, I'm also currently working on a template system (in Perl), and I've had quite similar

complaints about existing systems as you have mentioned. :)

It's nowhere near done yet as I'm also partially doing it to learn Perl, but I've had

some very similar ideas to what I'm seeing here.

What language do you intend to write the parser in? Or are you just trying to develop

the actual templating language and leave the parser to somebody else (of course one

could develop parsers in multiple languages)?

EDIT:

One of the things I've decided are important to me is that the template itself would

need to be valid HTML. This would allow you to validate your templates in their raw

state. From what I can tell you have indeed accomplished that here, which I quite like.

BUILD LOGS: HELIOS - Latest Update: 2015-SEP-06 ::: ZEUS - BOTW 2013-JUN-28 ::: APOLLO - Complete: 2014-MAY-10
OTHER STUFF: Cable Lacing Tutorial ::: What Is ZFS? ::: mincss Primer ::: LSI RAID Card Flashing Tutorial
FORUM INFO: Community Standards ::: The Moderating Team ::: 10TB+ Storage Showoff Topic

Link to post
Share on other sites

Ha, I'm also currently working on a template system (in Perl), and I've had quite similar

complaints about existing systems as you have mentioned. :)

It's nowhere near done yet as I'm also partially doing it to learn Perl, but I've had

some very similar ideas to what I'm seeing here.

What language do you intend to write the parser in? Or are you just trying to develop

the actual templating language and leave the parser to somebody else (of course one

could develop parsers in multiple languages)?

 

I'll probably do a first draft of it in PHP since that's what the rest of the project is in, and is the language that I mainly use. Obviously PHP isn't going to be the most efficient method though, even once I do caching of compiled templates, so I'll probably end up porting it to a C library and making a PHP extension from it. However, the language that it's implemented in is intended to be completely separate from the template language itself because I want to be able to pick it up and drop it into just about any project. Obviously using PHP/perl style $ prefixed variables would be nonsensical in a language such as C, so that's the kind of thing I want to avoid.

 

The current plan is to be able to register variables and functions with it, meaning that it effectively runs in a completely separate environment to the host language. Not only would that allow more control, but it would also inadvertently aid security, since you wouldn't be able to just dump database configuration, for example.

 

Edit to address your edit:

 

EDIT:

One of the things I've decided are important to me is that the template itself would

need to be valid HTML. This would allow you to validate your templates in their raw

state. From what I can tell you have indeed accomplished that here, which I quite like.

 

EDIT 2: So IPB decided what I just wrote wasn't worth saving... or I did something wrong - the latter is probably more likely :P

 

I basically said that while I felt it's outside the scope of the parser to validate templates as HTML, keeping the template language as valid HTML would certainly be a benefit that I hadn't considered, as it would avoid breaking any syntax highlighting in editors, and also would allow for the templates to be validated elsewhere in the application.

Link to post
Share on other sites

I'll probably do a first draft of it in PHP since that's what the rest of the project is in, and is the language that I mainly use. Obviously PHP isn't going to be the most efficient method though, even once I do caching of compiled templates, so I'll probably end up porting it to a C library and making a PHP extension from it. However, the language that it's implemented in is intended to be completely separate from the template language itself because I want to be able to pick it up and drop it into just about any project. Obviously using PHP/perl style $ prefixed variables would be nonsensical in a language such as C, so that's the kind of thing I want to avoid.

That sounds like a pretty good plan.

The current plan is to be able to register variables and functions with it, meaning that it effectively runs in a completely separate environment to the host language. Not only would that allow more control, but it would also inadvertently aid security, since you wouldn't be able to just dump database configuration, for example.

Security is definitely important, yes.

Edit to address your edit:

 

 

 

EDIT 2: So IPB decided what I just wrote wasn't worth saving... or I did something wrong - the latter is probably more likely :P

Nah, the forum is still a bit buggy at the moment. Especially when editing posts there

can be undesired behavior (for example: from time to time the input sanitizer doesn't

work correctly and sanitizes your post twice, therefore encoding the underlying HTML

again. Rather annoying on long posts).

I basically said that while I felt it's outside the scope of the parser to validate templates as HTML, keeping the template language as valid HTML would certainly be a benefit that I hadn't considered, as it would avoid breaking any syntax highlighting in editors, and also would allow for the templates to be validated elsewhere in the application.

Yes, I wouldn't necessarily integrate the validation into the parser itself. There

are many decent validators (I usually use the W3C one), no need to reinvent the wheel

on that one.

Syntax highlighting is actually the primary reason why I'm striving for valid HTML.

Especially when you're using an editor with autocomplete functionality (which, for

example, automatically inserts a closing tag when you type a new opening tag) this

would probably be quite useful. I don't, but there's lots of people who seem to be

rather fond of them. Having the templating language interfere with the HTML could

lead to some rather annoying behavior in such an editor.

BUILD LOGS: HELIOS - Latest Update: 2015-SEP-06 ::: ZEUS - BOTW 2013-JUN-28 ::: APOLLO - Complete: 2014-MAY-10
OTHER STUFF: Cable Lacing Tutorial ::: What Is ZFS? ::: mincss Primer ::: LSI RAID Card Flashing Tutorial
FORUM INFO: Community Standards ::: The Moderating Team ::: 10TB+ Storage Showoff Topic

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×