This is a repost from an exchange on the Rails mailing list. I got a recommendation to give it a more permanent home and share it with the world. We had a long running thread on whether Rails would benefit from some form of Amrita-style template language that "doesn't contain any code". Steve Longdo wrote about that:
The designers that a lot of the rest of the world works with aren't
the same caliber as 37 signals by a long shot. Dreamweaver expert
does not likely yield a decent ruby/rhtml coder...
i think it's better to get the designer work as close to the real thing
as possible. that also avoids wasting time.
And I wrote about how we work at 37signals...
I concur that its a false dichotomy. The designers at 37signals are not Ruby programmers. What they are capable of is reading english-like code fragments and move them around accordingly.
This is how we work:
Designer cooks up static HTML template.
Programmer sprinkle it with rhtml tags to make the dynamic elements
dynamic.
Designer and programmer can both revisit the template to make
changes.
The reason step 3 is possible is exactly what forces good programmer behavior in the templates:
<% if @user.is_administrator? %>
# show stuff that's only for administrators
<% end %>
...or
<% for comment in @post.comments %>
<h2><%= comment.headline %></h2>
<% end %>
No matter how "easy" you make your template language, new dynamic templates are not going to originate from the designers. What you can make possible is cooperation around the same templates once they're alive.
I remain utterly unconvinced that Amrita-style templates are going to do much anything than please the aesthetics that have fallen in love with <li oid="people">Loop</li>. It's not going to put designers in the driver's seat for new templates. And even the one promise of being able to edit in Dreamweaver falls to the wayside when you introduce layouts, partials, or other productivity techniques for dealing with templates.
The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It's mirage, but its also a play on words of the "a rose by any other name..." variety.
Code is just another word for decisions about instructions. Whether those decisions are made through indirection and tag decoration, they are still decisions about instructions. That is, its still code.
With all that said, I shall not stand in the way for the pursuit of another man's aesthetic dreams. Many will know that I guide many decisions about Rails from my own sense of aesthetics all the time. I'd feel a lot more at ease about it if the proponents of Amrita-style templates would just confess, or realize (as the true motive may still lie in the subconcious ;)), that the pursuit is one of aesthetics.
So. If you want to try this out, feel free. Should a truly non-intrusive solution emerge, I shall even give it serious thought as whether to include it.
UPDATE: The reason why I think the whole notion of code-less templates have taken hold is because people have been used to languages that were utterly unsuited for template logic. The template languages presented a less painful way to add logic and due to the lower pain associated with their use, it grew too tempting to fit in inappropriate code to them.
That's totally different with Ruby on Rails. First of all, Ruby is an excellent language for view logic (succinct, readable) and Rails is also made out of all Ruby. So there's no longing for a better suited template language and there's no pain relief in misappropriating business logic into the view.
For an example of a rose by any other name, take a look at this:
http://rafb.net/paste/results/lvldAQ21.html
Many programmers seem to think that if it is markup, it can't be logic/code. But the fact is, a conditional is a conditional, and a loop is a loop, even if the procedure call is abstracted out of the template (as it is in Amrita and RIFE).
Few people would claim that XSLT doesn't contain logic, and like these templating languages do similar things as XSLT.
Challenge by Morten on February 14, 18:21
Separation of content and logic has been a concern in web-development since circa 1999-ish?
IMO, we haven't gotten much better since then. The "tag soup" syndrome of some server pages languages is no less confusing than well delimited snippets of logic in my eyes.
If you're consistent in style, and refactor larger code snippets into eg. helpers, I doubt any designer would have trouble abstracting away the code segments. I have yet to meet one, have anyone here had problems explaining designers what's code and what's not?
The only argument I see for using a "template engine" as opposed to what Rails has now is to allow UNTRUSTED users to edit templates (i.e. as a journal template editor for a mass-hosted journaling solution). In these rare cases, a developer might wish to ensure that it's users aren't capable of breaking into FULL Ruby and extending some class or gathering some data that they shouldn't have access to. In this case, it isn't aesthetics they are after, but security.
Templates can increase security which might be a factor for larger organizations. I always thought the main reason for templates was to keep people from spamming /etc/passwd to the world. This is also important if you are developing a product that will be resold and customized by clients.
If you ever do consider integrating a templating system into rails please look at clearsilver.net. If you have to use templates, it doesn't get any better than clearsilver! This is the templating engine used by bloglines, google groups2 and yahoo groups.
I think that in situations where the code for a given "page" can be in more than one place -- e.g. in the View and the Controller -- templating helps enforce a certain discipline. Otherwise, I think the temptation to fix bugs or tweak things by quickly putting code in the View is too great.
That's not to say that the View is code-free, but rather that the distinction is clearer -- and better enforced.
[since you posted your email to your blog, I'll do the same, in the hopes that you can respond to my particular question)
It's interesting that you have this opinion, because I've actually
implemented a language like Amrita (in the dotnet world) recently, hoping that will improve the step (3) that you talk about. It seemed to me that if you allow the designer to make static html with maybe a lot of dummy data to mockup the design, and keep that dummy data in after the page has been made dynamic, that could improve the template's ability to be round-tripped from designer to developer and back. I do think you'd have to add a "remove" attribute to the Amrita language to support this, though, so the designer could have 50 rows of dummy data and hide 49 of them when it runs dynamically.
Your code examples would look like this in the language I wrote:
...or
Some headline lorem ipsum...
Some text ... lorem ipsum dolor ...
(I expanded the second example to fit what I think is your intention, printing the comment contents as well as headline).
So, I ask you, if the goal isn't to put the designer firmly in control
or make some revolution, but just to streamline the post-dev
roundtripping process, do you still think it's a terrible idea? I'm
not trying to bait you ... I'm just already invested somewhat in this direction and would like to get feedback early.
The reason I love Amrita so much is that I can use a purely XML-reading, XHTML-compliant editor, scripts or whatever to edit templates. It's not that I don't want to understand what's going on, it's that I want to apply the same rigourous parsability to the templates that I'd want to be able to apply to the output.
The tools I want to be using don't entirely exist yet. However, I really do want to be using things like NVU to edit my templates, when it's to an acceptable level. I don't want to have to hand-tweak anymore. And I don't want my templating system to be the thing holding me back when the tools are all there.
Steve, the test data situation and the whole notion of being able to preview the HTML falls apart as soon you introduce template productivity tools like layouts and partials. These approaches chop up the templates into minor files that in isolation doesn't make much if any sense to preview.
So no, I don't see how this approach helps round-tripping. Having tons of dummy data certainly doesn't help with the overview of the HTML either. The first thing I do when receiving a HTML file with dummy data is to shave it down to the one instance I need to iterate over, so the template is more manageable.
I agree that if every template was made as a full, self-contained HTML page this approach would be of more interest. I also agree that it does look kinda pretty.
What I don't agree with is that its worth sacrificing the use of Ruby in templates or to introduce the indirection necessary, when this still doesn't allow the designer to edit his page in a WYSIWYG editor anyway.
So given all aspects, it seems like waay more pain than gain to pursue. But again, I recognize that this approach is deeply aesthetically pleasing, which is reason enough to pursue it. I'm just rejecting the "rational" wrapper arguments as I don't see them hold any merit.
Our designers never deliver anything but Photoshop comps or at best slices, and I wouldn't want it any other way. It's all about delivering a quality product and the graphic designers should focus on the design, and you as a programmer on the implementation.
one advantage of template languages that you didn't really touch on is language independence. eg, there are implementations of TAL for python, perl, php, java, and probably other languages. where i work, we use all of those languages for building applications. our designers get swapped between projects and having to only know one template language is a huge advantage. our designers are really clever, but expecting them to know 5 different languages would really distract from their main job of actually *designing* things.
i used to be a big perl fan but have moved to python in the last couple years. luckily, i used a templating language so i've been able to rewrite some of my old perl applications in python without making any changes to the templates.
Challenge by Tim Mirecki on February 26, 18:32
In regards to what Simen Brekken said on February 15, I don't think the graphic designers OR programmers should have to be tweaking template designs. For this reason, I've implemented a 3-level process in my organization.
1. Design Photoshop comps (graphic designer)
2. Transform PSDs into pure XHTML/CSS (web designer)
3. Implement templates into application (developer)
Note the distinction between the graphic and web designers - they have their own strengths but sometimes it's hard to find someone who does both well. Usually graphic designers are good with Dreamweaver but not with the hardcore XHTML stuff.
The developer is then free to focus on the application and not worry about the template at all. By the time he gets the template, it's 99.9% of what it needs to be to fit into the framework.
This process has been working very well for the past 6 months or so, although it took some initial explaination to wrap people's heads around the difference between a photoshop template and an XHTML template.
In my attempt this January to build a template engine that runs in a web browser (perhaps a foolish goal, no?), I ended up with a data point that I think helps support your thesis. This February, I started learning Ruby/Rails, and found my template language feels a bit like ERB, even though I didn't know ERB at the time.
Of course, my template language is based on JavaScript, not Ruby. Take a look at JavaScript Templates engine...
http://trimpath.com/blog/index.php?p=3
I believe that JavaScript is also a view-logic-friendly language, but arguably less so than Ruby.
