PageRenderTime 23ms CodeModel.GetById 17ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 1ms

Visualforce Page | 61 lines | 32 code | 29 blank | 0 comment | 0 complexity | bf53c5d0fc6be0c23a3eed7db3cec23b MD5 | raw file
 2title: Is putting code in the view bad?
 3in_menu: false
 4--- name:overview
 6# Is putting code in the view bad?
 7Code in view bad? It all depends...
 9--- name:content
10A 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. 
12In 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 :)
14## Lift views
16Even 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.
18This has pros and cons. 
20### Whats good about Lift views
22You 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.
24This lets you have different people editing the templates from the people writing the Scala code to render markup from your domain objects.
26### The downsides of Lift views
28If 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. 
30There'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 :-)
32As 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.
34## Scalate views
36The 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.
38### Whats good about Scalate views
40The 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](creating-ide.html) from any expression or function in your template to the corresponding Scala code.
42So 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.
44If 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.
46### The downsides of Scalate views
48The 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. 
50Most web design tools can work with JSP syntax so hopefully they can handle [Ssp templates](documentation/ssp-reference.html) too without too much problem. Though they probably won't handle the [Scaml format](documentation/scaml-reference.html).
53## Conclusion
55Template languages are quite personal things so the choice between Lift views and Scalate's [Ssp](documentation/ssp-reference.html) or [Scaml](documentation/scaml-reference.html) 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. 
57If 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.
59What do you think? [Let us know](community.html)