A common response we hear from folks; particularly folks using Lift is that putting code in views is bad. Blanket statements like that are often not that great themselves :), we really think it depends on your personal preferences, requirements and the makeup of your team.
In this article we'll compare and contrast Lift and Scalate views listing their strengths and weaknesses. We'll try to be impartial; though do notice which website you're reading this page on - it might be a little biased in Scalate's direction :)
Even with the Lift approach there is code in the views; its just the code is hidden behind an XML element which when the right snippet is invoked, gets replaced by some code to be the value of another Scala expression. So your view still has code inside it, but there's a level of indirection between actual Scala code and the template which just refers to custom tags.
This has pros and cons.
You can give a lift template to someone incapable of writing scala code; they can edit it and provided they don't edit any of the special tags and the template remains in an XML-like format you're fine. They can even add in a whole bunch of new tags if they want; if the Scala hacker hasn't implemented them yet, they'll just be rendered in the HTML as markup.
This lets you have different people editing the templates from the people writing the Scala code to render markup from your domain objects.
If the same people are editing the template and writing the scala code you're adding lots of unnecessary work since you are adding a level of indirection between the template and the scala code which adds unnecessary work. For every expression, loop or conditional block you want to put into a view you need to introduce a new custom tag; then write a snippet method to transform the markup replacing the custom tag to the actual expression you want.
There's also the opposite issue if you are not careful; rather than too much code in the view; there's too much view in the code (too much view being defined inside Scala code where your designer can't see or edit it and not enough view in the template :-)
As the number of templates grow the number of custom tags and markup transformation methods grow this can become hard to maintain. Maybe its just me being dumb but I often find on non-trivial pages with multiple levels of namespace prefixes, nesting and tag replacement method snippets I get a bit confused at times between what tag names and namespace prefixes I'm using. If nothing else its certainly much more mental gymnastics than just using the Scala expression or function call you need in your template when you need it - particularly when you revisit an old template/snippet method weeks after you wrote it.
The Scalate approach is to use Scala expressions inside the template; so there's no transformation step or a need to mentally map namespace prefixes and element names to blocks of Scala code.
The templates are much simpler to understand and edit; you can look at a template and know exactly whats its doing. Since Scalate is just using Scala, ultimately your IDE should be easily able to navigate from any expression or function in your template to the corresponding Scala code.
So if the same folks are maintaining the templates as writing the Scala code there's much less work to do. It might be that tactically some templates end up with a bit too much Scala code in there; at which point just do a refactor - move the scala code to a separate template or Scala function.
If you have separate designers who focus on the markup, you can let them create the mockups that your Scala coders then edit to add the Scala expressions.
The main downside is that if you give a Scalate view to a designer they can break the code since there are scala expressions inside the templates. Though since Scalate templates can be compiled at build time, your continuous integration build should catch that.
Most web design tools can work with JSP syntax so hopefully they can handle Ssp templates too without too much problem. Though they probably won't handle the Scaml format.
Template languages are quite personal things so the choice between Lift views and Scalate's Ssp or Scaml may well just be a taste thing. One of the biggest reasons for choosing Lift or Scalate is likely to be the makeup of your team and their skills.
If you have one or more designers who own the templates and who don't code in Scala; then lift views are probably the best choice. If the same team maintain the templates and hack your Scala code (maybe using designers to create mock ups) then we think the Scalate templates are easier to create and maintain so a better choice.
What do you think? Let us know