HTML templating that works in more than one language?


R

Ruby Baby

Has anyone seen an HTML templating system that would be
usable from Ruby *AND* PHP and perhaps other languages?

So far, if you want your HTML templates to do anything
more than simple variable replacement that the template
language becomes a lot like the language it's written in.

I'm thinking particularly of Smarty (for PHP):
http://smarty.php.net/manual/en/smarty.for.designers.php

Do you think a Ruby class could ever parse Smarty templates,
including basic 'each' logic like this:?
http://smarty.php.net/manual/en/language.function.foreach.php

Any other advice appreciated.
This is just for HTML templates, that need logic and loops,
but we might have a project that uses both Ruby and PHP,
and of course we don't want to re-write HTML templates
for each.

Thanks!
 
Ad

Advertisements

S

Stefan Scholl

Has anyone seen an HTML templating system that would be
usable from Ruby *AND* PHP and perhaps other languages?

Not the best solution, but have you thought about using XSLT?
 
L

Lothar Scholz

Hello Ruby,

Friday, January 16, 2004, 4:29:56 AM, you wrote:

RB> Has anyone seen an HTML templating system that would be
RB> usable from Ruby *AND* PHP and perhaps other languages?

RB> So far, if you want your HTML templates to do anything
RB> more than simple variable replacement that the template
RB> language becomes a lot like the language it's written in.

RB> I'm thinking particularly of Smarty (for PHP):
RB> http://smarty.php.net/manual/en/smarty.for.designers.php

RB> Do you think a Ruby class could ever parse Smarty templates,
RB> including basic 'each' logic like this:?
RB> http://smarty.php.net/manual/en/language.function.foreach.php

RB> Any other advice appreciated.
RB> This is just for HTML templates, that need logic and loops,
RB> but we might have a project that uses both Ruby and PHP,
RB> and of course we don't want to re-write HTML templates
RB> for each.


I doubt that this is usefull because you must embedd a complete
php interpreter in ruby.

The only way to go seems to be the amrita way with a templating engine
that works on pure html. I know that there is something for python
(the ZTL Zope Template Language).
 
M

messju mohr

Hello Ruby,

Friday, January 16, 2004, 4:29:56 AM, you wrote:

RB> Has anyone seen an HTML templating system that would be
RB> usable from Ruby *AND* PHP and perhaps other languages?

RB> So far, if you want your HTML templates to do anything
RB> more than simple variable replacement that the template
RB> language becomes a lot like the language it's written in.

RB> I'm thinking particularly of Smarty (for PHP):
RB> http://smarty.php.net/manual/en/smarty.for.designers.php

RB> Do you think a Ruby class could ever parse Smarty templates,
RB> including basic 'each' logic like this:?
RB> http://smarty.php.net/manual/en/language.function.foreach.php

RB> Any other advice appreciated.
RB> This is just for HTML templates, that need logic and loops,
RB> but we might have a project that uses both Ruby and PHP,
RB> and of course we don't want to re-write HTML templates
RB> for each.


I doubt that this is usefull because you must embedd a complete
php interpreter in ruby.

smarty converts templates written in it's own language to php-code and
runs this php-code. there is no php-code in a smarty-template.

if a ruby class converts the same template to ruby-code no
php-interpreter is needed.

but smarty was written with 100% php in mind. the structures may not
map that nicely to ruby. but i'm sure it's possible if somebody want
to put the effort in it.

greetings
messju
 
J

jason r tibbetts

Quoting messju mohr said:
smarty converts templates written in it's own language to php-code and
runs this php-code. there is no php-code in a smarty-template.

if a ruby class converts the same template to ruby-code no
php-interpreter is needed.

but smarty was written with 100% php in mind. the structures may not
map that nicely to ruby. but i'm sure it's possible if somebody want
to put the effort in it.

And it wouldn't have to be that much effort, especially if the OP's suggestion
(foreach) is an indication of the complexity. In fact, the example that's listed
on the OP's link is a dead-simple mapping to Ruby:

Smarty:
{foreach name=outer item=contact from=$contacts}
{foreach key=key item=item from=$contact}
{$key}: {$item}<br>
{/foreach}
{/foreach}

Ruby:
contacts.each() do | contact |
contact.each_pair() do | key, item |
puts "#{ key }: #{ item }<br>"
end
end

In fact, if this is as tough as it gets, writing a Ruby interpreter for Smarty's
syntax should take no time at all, even for a beginner in the language (like me).

--
jason

:wq
___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet
 
M

messju mohr

And it wouldn't have to be that much effort, especially if the OP's suggestion
(foreach) is an indication of the complexity. In fact, the example that's listed
on the OP's link is a dead-simple mapping to Ruby:

Smarty:
{foreach name=outer item=contact from=$contacts}
{foreach key=key item=item from=$contact}
{$key}: {$item}<br>
{/foreach}
{/foreach}

Ruby:
contacts.each() do | contact |
contact.each_pair() do | key, item |
puts "#{ key }: #{ item }<br>"
end
end

In fact, if this is as tough as it gets, writing a Ruby interpreter for Smarty's
syntax should take no time at all, even for a beginner in the language (like me).

"no time at all"? that would be infinitely fast. even ruby doesn't
provide prototyping that rapid :)

with "effort" i didn't mean "complicated" or "challenging", i meant it
more in the sense of "tedious".

greetings
messju
 
Ad

Advertisements

D

Dan Janowski

IClearsilver

www.clearsilver.net

I use it exclusively for HTML and it is the best templating system I
have ever come across. Both powerful and clean. XSLT is complex and
other embedded templating (PHP, JSP, ASP) are mixing monkeys and fire
wood in the same basket.

I have written an extension for Ruby which is included in the package.
For PHP, I have written a class that invokes clearsilver as a
subprocess. Less efficient, but it never posed a problem for my
application. There are some clever ways of working with it.

Let me know if you want some more info on it.

Dan
 

Top