Everyone who’s done any web application development in Scala knows that you can use any existing Java web framework, or you can use Lift. Something that all of these frameworks have in common is that they all require two or more files to generate a page: an HTML template of some kind, and one or more classes to provide associated logic. Even if you’re writing a JSP-only app, you’re probably still making use of lots of custom tags.
And this brings me to something I’ve noticed: the template files often bear little resemblance to HTML. Wicket template files are pretty much HTML because in Wicket, components bind themselves to HTML tags in the template. But in all the frameworks that are based on custom tags, the templates are generally full of custom tags and are not renderable in a browser on their own.
Scala supports embedding arbitrary XML directly into the program source. Here is a Scala function that make an unnumbered list from a collection:
def listify[T](items: Iterable[T], liBody: T => NodeSeq) = <ul>{
items.flatMap(i => <li>{liBody(i)}</li>)
}</ul>
Now if I have that, I’ve already abandoned architectural purity because I have ul and li tags in the “controller,” or “business logic,” or “backing object,” or whatever you call it, and not in the template. Yet this is a pretty clear and straightforward way of creating a list. Doing it any other way requires substituting some run-time tag-binding framework in place of Scala’s own built-in features.
So I’m wondering, why not just go the other way and get rid of the templates? If Scala is useful for creating an unnumbered list, then why can’t it also create whatever contains the unnumbered list? And all the way up the page back to the html tag.
The question I’m asking is: given a language that already includes powerful support for XML, are there significant benefits to using template files and transforming them into actual HTML at run time, or is it better to just consider template files as artifacts carried over from languages without built-in XML support and abandon them?
I think the main reason is for tooling support. It is easier to support tooling when part of the project is strictly XML (the template files). It is far trickier (though not impossible), to manipulate code from a design tool.
Also, in most production environments, the abstraction of business logic from the “view” (using whatever paradigm you like best, MVC, MVP, etc..) is critical. Any project large enough would likely be too unwieldy to go without it. Remember that in production environments, there are often more than one programmer, and sometimes new programmers join the team or existing ones move, so it’s not really optional. Most of the efforts of web framework designers are invested in this use case, so functionality which breaks this abstraction is less of a priority.
However, I could see where an internal scala DSL for web development might be useful for small projects. It would certainly not be unwise to invest your time in creating a light-weight framework for such use, if you would find it useful. Chances are, if you created it and found it useful, others might too.
Suggested resources: