Looking for HTML templating system

ruby-talk
1

From: Ruby Baby [mailto:ruby@hitmedia.com]

it seems smarter to shift your focus from “HTML templates to
put my Ruby in” to “Ruby class that puts out HTML”.

Templates are templates, there should be no logic
in them; they are only presentation.

Presentation DEFINITELY needs logic, for anything beyond the
stupidest “put a variable on a page” website.

The differences is that a templating system should only have
PRESENTATION LOGIC, but no business-logic.

The presentation having logic is a big part of making an
easy-to-use responsive website!

For example, my site is http://www.cdbaby.com

The presentation/display is constantly changing based on the
contents. It is deciding how it wants to present the business
information given to it.

If an item is on sale, the designer has decided to put a big
yellow flag in the top-right corner. If it is one hour until
we close, the designer has decided to change the color of the
page to let the customer know we’re almost closing, and they
should hurry. The designer has decided to capitalize the
artist names, and lowercase the album titles.

All of this is presentation logic.

I’d take some issue with this. Sort of. The colour of the flag is (should
be) in the realms of the designer, but the fact that it changes is in the
realms of the business - “closing” is a concept rooted in your business, not
in your web frontend. The “1 hour” rule is also a piece of business logic.

The line is softly drawn in wet sand on a very wet beach in between waves -
but I don’t think there is a lot of “presentation logic” that is not
governed by business rules. So very little logic should exist on the
presentation side of templates.

(IMO).
David Naseby
http://homepages.ihug.com.au/~naseby/

2

Templates are templates, there should be no logic
in them; they are only presentation.

Presentation DEFINITELY needs logic, for anything beyond the
stupidest “put a variable on a page” website.

The differences is that a templating system should only have
PRESENTATION LOGIC, but no business-logic.

The presentation having logic is a big part of making an
easy-to-use responsive website!

For example, my site is http://www.cdbaby.com

The presentation/display is constantly changing based on the
contents. It is deciding how it wants to present the business
information given to it.

If an item is on sale, the designer has decided to put a big
yellow flag in the top-right corner. If it is one hour until
we close, the designer has decided to change the color of the
page to let the customer know we’re almost closing, and they
should hurry. The designer has decided to capitalize the
artist names, and lowercase the album titles.

All of this is presentation logic.

I’d take some issue with this. Sort of. The colour of the flag is (should
be) in the realms of the designer, but the fact that it changes is in the
realms of the business - “closing” is a concept rooted in your business, not
in your web frontend. The “1 hour” rule is also a piece of business logic.

The line is softly drawn in wet sand on a very wet beach in between waves -
but I don’t think there is a lot of “presentation logic” that is not
governed by business rules. So very little logic should exist on the
presentation side of templates.

I guess from my experience I feel that the business-logic is the code that
generates the attributes and such, ready to pass off to the template as
strings, hashes, and arrays.

But once you give that information to the template, it’s up to the template
to decide what to do with it.

Here’s a better example:

For any item you put in your shopping cart, my business-programming can
give you a list of 20 items for “If you like this you will like…”

But it’s up to the visual design to decide how many of those 20 items
to show on the screen at once. Maybe for beauty or usability, the designer
only wants 3. So to do that, she would need “length” and “each” or “times”
methods.

Seems to me, template logic could do a lot with just:

  • if / else
  • each / times
  • length
  • basic string formatting

But if you’re going to write a whole new mini-language to reduce Ruby
(or any language) down to these few options, why bother? Same amount of
time to teach your designers a mini-language as to just teach them the
same few methods in Ruby, but using real Ruby instead of some invented
subset. But much less useful to have a subset instead of just Ruby.

Sorry to be discussing this on the Ruby list, but I’m seriously considering
rewriting cdbaby.com in Ruby, and have been thinking about this template
issue a LOT lately. So to me, it really is tied in with Ruby itself.

3

Ruby Baby wrote:

I guess from my experience I feel that the business-logic is the code that
generates the attributes and such, ready to pass off to the template as
strings, hashes, and arrays.

But once you give that information to the template, it’s up to the template
to decide what to do with it.

Here’s a better example:

For any item you put in your shopping cart, my business-programming can
give you a list of 20 items for “If you like this you will like…”

But it’s up to the visual design to decide how many of those 20 items
to show on the screen at once.

I agree on this point; the template needs some basic methods to process
strings, iterate over lists etc. And I think that constructing a new
mini-language really makes no sense if you are already using a
scripting language that can be easily embedded into the template. But
what I am not yet sure about is how to do it in practice. Example: The
forum has to determine which page to show (forum list, thread view,
login form) based on a variable/attribute, let’s call it “action”. Now
I could do something like this in the template (pseudo-eruby):

.... <% case action %> <% when "forumlist": %> <%=include("forumlist.tpl") %> <% when "loginpage": %> <%=include("loginform.tpl") %> <% end %> ....

Any better ideas?