This is a useful project with some excellent documentation. My compliments. I use Jakarta Velocity for this type of thing now, but your solution is considerably more lightweight and probably has all I'd need in most circumstances.
However, I have one complaint. The syntax of your template language is not XML-compliant. Probably you're just following the syntax of the Perl HTML::Template project that you based this off. The compatibility may be useful for some, but I don't care at all about it, and in this day of XML everywhere it looks terrible to see the messy HTML-style syntax.
Do you have any plans to make the syntax XML-compliant, or will you be sticking to the current syntax for backwards compatibility?
Thanks,
Pete Cassetta
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, glad you like it. Yes, I do need to maintain
HTML::Template compatibilty in the tags. I do
have a few projects that mix java and perl
and it's useful to be able to use the same
templates.
I think that XML syntax can be added in easily
using a Filter. Filters aren't ready yet, I've
only just finished with the Filter Interface, but
once it's ready, I'm pretty certain we could have
a predefined filter specifically to handle XML
syntax.
Maybe you can help out by telling me what changes
would have to be made to the tags.
Cheers,
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<Philip>
Maybe you can help out by telling me what changes
would have to be made to the tags.
</Philip>
Basically 2 or 3 XML syntax rules need to be implemented:
1) All tags are terminated. Those with an empty body look like <tag/>. Those with a body look like <tag>body</tag>.
2) Tags and attribute names are case-sensitive. I think your examples sometimes use lower-case, other times upper-case, so you'd have to be more standard.
3) Attributes all have the syntax name="value" with the value in double quotes.
Let's look at a code snippet:
<tmpl_if name>
Your name is <tmpl_var name>
<tmpl_else>
You did not give a name
</tmpl_if>
This needs quite a bit of modification:
<tmpl_if name="name">
Your name is <tmpl_var name="name"/>
<tmpl_else>
You did not give a name
</tmpl_else>
</tmpl_if>
Some notes:
1) Where I used the attribute name "name" you could actually use anything that makes sense. But you have to standardize it of course.
2) The "else" clause is messy in XML. My example above is only one way to do it. Another would be:
</tmpl_if><tmpl_else>
</tmpl_else>
There is no real requirement for the template language to be XML-compliant. It just looks awfully odd to me as an HTML-style language. I haven't seen anybody design a new tag language in the last couple of years which wasn't XML-compliant. XML-compliance would make it easier to parse and read the document with a program, but only if the document is XHTML. If it's HTML, then the document won't be XML compliant anyway.
I guess I'm not convinced this is an important feature, it just looks awful to me at first glance.
I just noticed this line from the examples:
<TMPL_VAR name="var_name" default="my value">
This, interestingly, is XML-compliant (except that you should probably stick to lower-case for "TMPL_VAR". So are these two both legal now:
<tmpl_var name>
<tmpl_var name="var_name">
If so, and you could handle closing the tag with "/>" then the second syntax would be XML-compliant.
Anyway, the simplicity and elegance of the project is there. I may try using it in places where I now use Velocity, to see how it flies. It's so lightweight, and I really like that.
By the way, if you're not familiar with Velocity, it uses a ${expression} syntax for the tags. Quite similar to the JSP 2.0 expression language. You stick objects into a Velocity "context" which is quite similar to a hash table. Then the expressions use reflection to extract values. So you don't have to be quite as explicit about what you put into the context. Put a complex object into the context via one statement, and then your template can use all sorts of getter methods to extract data. I believe that with your system, you'd have to put in all the individual named data items into the template as parameters or build a hashtable with all these values and then stick it into the template.
I do like your looping syntax, your "escape" attribute, and your "default" attribute.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, the correct template syntax is <tmpl_var name="var_name" [escape="html|url|quote|none"> loops are: <tmpl_loop name="loop_name"> conditions are <tmpl_if name="conditional"> and includes are <tmpl_include name="filename">
template tags are not case sensitive, so it's okay if you say tmpl_var or TMPL_VAR or TmPl_Var. I don't think this is a problem, since if your tags look like the last one, you've got bigger problems than XML compliance anyway ;)
Parameter names are by default not case sensitive, but through the case_sensitive constructor option, you can make them case sensitive.
The other forms of tags are basically shortcuts. I think my only crime there is using it in the HowTo. I should really have stuck to the long form of the tags.
I think the only thing to be supported is the / for tmpl_var. That's easy enough to do. I'll consider it.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Philip,
This is a useful project with some excellent documentation. My compliments. I use Jakarta Velocity for this type of thing now, but your solution is considerably more lightweight and probably has all I'd need in most circumstances.
However, I have one complaint. The syntax of your template language is not XML-compliant. Probably you're just following the syntax of the Perl HTML::Template project that you based this off. The compatibility may be useful for some, but I don't care at all about it, and in this day of XML everywhere it looks terrible to see the messy HTML-style syntax.
Do you have any plans to make the syntax XML-compliant, or will you be sticking to the current syntax for backwards compatibility?
Thanks,
Pete Cassetta
Hi, glad you like it. Yes, I do need to maintain
HTML::Template compatibilty in the tags. I do
have a few projects that mix java and perl
and it's useful to be able to use the same
templates.
I think that XML syntax can be added in easily
using a Filter. Filters aren't ready yet, I've
only just finished with the Filter Interface, but
once it's ready, I'm pretty certain we could have
a predefined filter specifically to handle XML
syntax.
Maybe you can help out by telling me what changes
would have to be made to the tags.
Cheers,
Philip
<Philip>
Maybe you can help out by telling me what changes
would have to be made to the tags.
</Philip>
Basically 2 or 3 XML syntax rules need to be implemented:
1) All tags are terminated. Those with an empty body look like <tag/>. Those with a body look like <tag>body</tag>.
2) Tags and attribute names are case-sensitive. I think your examples sometimes use lower-case, other times upper-case, so you'd have to be more standard.
3) Attributes all have the syntax name="value" with the value in double quotes.
Let's look at a code snippet:
<tmpl_if name>
Your name is <tmpl_var name>
<tmpl_else>
You did not give a name
</tmpl_if>
This needs quite a bit of modification:
<tmpl_if name="name">
Your name is <tmpl_var name="name"/>
<tmpl_else>
You did not give a name
</tmpl_else>
</tmpl_if>
Some notes:
1) Where I used the attribute name "name" you could actually use anything that makes sense. But you have to standardize it of course.
2) The "else" clause is messy in XML. My example above is only one way to do it. Another would be:
</tmpl_if><tmpl_else>
</tmpl_else>
There is no real requirement for the template language to be XML-compliant. It just looks awfully odd to me as an HTML-style language. I haven't seen anybody design a new tag language in the last couple of years which wasn't XML-compliant. XML-compliance would make it easier to parse and read the document with a program, but only if the document is XHTML. If it's HTML, then the document won't be XML compliant anyway.
I guess I'm not convinced this is an important feature, it just looks awful to me at first glance.
I just noticed this line from the examples:
<TMPL_VAR name="var_name" default="my value">
This, interestingly, is XML-compliant (except that you should probably stick to lower-case for "TMPL_VAR". So are these two both legal now:
<tmpl_var name>
<tmpl_var name="var_name">
If so, and you could handle closing the tag with "/>" then the second syntax would be XML-compliant.
Anyway, the simplicity and elegance of the project is there. I may try using it in places where I now use Velocity, to see how it flies. It's so lightweight, and I really like that.
By the way, if you're not familiar with Velocity, it uses a ${expression} syntax for the tags. Quite similar to the JSP 2.0 expression language. You stick objects into a Velocity "context" which is quite similar to a hash table. Then the expressions use reflection to extract values. So you don't have to be quite as explicit about what you put into the context. Put a complex object into the context via one statement, and then your template can use all sorts of getter methods to extract data. I believe that with your system, you'd have to put in all the individual named data items into the template as parameters or build a hashtable with all these values and then stick it into the template.
I do like your looping syntax, your "escape" attribute, and your "default" attribute.
ok, the correct template syntax is <tmpl_var name="var_name" [escape="html|url|quote|none"> loops are: <tmpl_loop name="loop_name"> conditions are <tmpl_if name="conditional"> and includes are <tmpl_include name="filename">
template tags are not case sensitive, so it's okay if you say tmpl_var or TMPL_VAR or TmPl_Var. I don't think this is a problem, since if your tags look like the last one, you've got bigger problems than XML compliance anyway ;)
Parameter names are by default not case sensitive, but through the case_sensitive constructor option, you can make them case sensitive.
The other forms of tags are basically shortcuts. I think my only crime there is using it in the HowTo. I should really have stuck to the long form of the tags.
I think the only thing to be supported is the / for tmpl_var. That's easy enough to do. I'll consider it.
Philip
Philip,
So it looks like my complaints are really a non-issue. Sorry I didn't dig deeper than the tutorial, or this whole discussion could have been avoided.
So I can use XML syntax if I like. Except for the <else> clause. But if it really bothered me (it won't) I could always avoid <else> completely.
Thanks for the discussion anyway.