• Scalate
• Download
• Source
• Community
• Support
• Documentation

Scalate the IDE friendly template language

We specifically designed Scalate so that it should work amazingly well in an IDE since all expressions in the templates are Scala using static typing so that when you are editing a template the IDE knows all of the attributes and their types.

Your IDE should be capable of great completion and error checking; plus at edit time your IDE should know if you have made any typos in any of your expressions such as maybe getting the property name wrong on a bean you are displaying. Its very easy to make typos in templates!

Making it easier on the IDE hacker

Making great IDE plugins is a lot of work, but we hope we can cut some corners making great IDE plugins for Scalate because:

• most IDEs already have a plugin to support JSP or Erb editing and dealing with the syntax of mixing HTML/XML markup with a language (Java/Ruby). So for Ssp its just a case of reusing the core JSP/Erb editor with Scala language instead. JSP is pretty complex; Ssp is probably closer to the simplicity of Erb really
• for IDEs which support HAML already it should be relatively easy to provide Scaml support by just switching the language from Ruby to Scala for a very quick win (other than the change to Scala the differences are minimal).
• both Ssp and Scaml have very simple surface syntaxes that are easy for IDEs to parse; plus both parsers are implemented using Scala's excellent combinator parser libraries so they should be easy to reuse if you need them. Check out the source code for SspParser and ScamlParser
• all the clever stuff in a Scalate template is done by the Scala language which already has great IDE support.

JSR 45 Support

Scalate adds JSR 45 metadata to the template classes that it generates. This means that, when running in Java a debugger, browsing through stack frames of generated template classes will take you to the template file instead of the generated scala file. This feature should also allow IDE implementors to create Ssp and Scaml editors which allow you to set debugging breakpoints in the templates.

Types in scope for the Scala language completion

Other than detecting when there is a Scala code block or expression in the Ssp and Scaml template languages, the main thing for the IDE to do is to configure which variables are available and their types for error checking and completion. Here's a break down…

• the RenderContext is imported so its methods are available. Typically in web applications the ServletRenderContext is imported which adds a few Servlet specific methods (like request/response/session/servletContext/servletConfig); though in some uses and frameworks just a RenderContext that is in scope.
• each attribute declaration is available in scope (which maybe be imported too if the 'import' keyword is used)

For example the following Ssp script:

<%@ val bar: String = "this is the default value" %>
<%@ import val foo: Customer %>
<p>hello there ${name} and ${bar}</p>

could be considered to mean the following scala code (using << to refer to rendering output)

def render(context: ServletRenderContext, 
           bar: String = "this is the default value", 
           foo: Customer): Unit = {

  import context._
  import foo._
  
  << "<p> hello there"
  << name
  << " and "
  << bar
  << "</p>"
} 

The purpose of the above isn't to give a faithful representation of how output is generated (its similar to the above but you could always look at the actual generated scala code in WEB-INF/_scalate/src/foo.ssp.scala to see for sure) - its more to show what variables are in context for the purpose of compiler warnings and method completion.

So in the above the “name” expression is resoved by the foo variable's import for example.

We're here to help!

If you are considering hacking an IDE plugin for Scalate we're more than happy to help you out, please get in touch! Many thanks!