New Web Framework Builds on Scalatra and Scalate
The importance of Scalatra and Scalate cannot really be underestimated in the creation of Bowler.
Bowler is the latest web framework to be written in Scala. JAXenter spoke to creator Wille Faler to find out what makes this framework different…..
JAXenter: You recently announced the first release of the ‘Bowler’ framework. What is Bowler?
Wille Faler: Bowler is a RESTful web framework written in Scala which can specifically ease development of multi-channel webapps that need to support web, mobile web for multiple devices and REST API’s. I think customization of web content for a plethora of channels such as full desktop/laptop browsers, tablets, smart phones, third party mash-ups and thick client apps is something that we’ll see even more of going forward and Bowler is trying to make addressing this challenge as easy as possible.
Being the new kid on the block, comparisons are inevitable, so I’ll bite that bullet: I have tried to pick, choose, adapt and improve on some of the best ideas from some of my favourite other frameworks, for instance I wanted to at least match the approachability and developer productivity of something like Rails and Play Framework, while having similar levels of UI re-use as Apache Wicket Components/Panels or Lift Snippets. Someone also made a comparison to the Padrino, the Ruby framework, and I guess considering Bowler’s Scalatra based lineage that similarities in URL routing to frameworks like Sinatra and Padrino are inevitable.
JAXenter: What does Bowler offer, that other frameworks do not?
Wille Faler: The main difference between Bowler and other frameworks is that it makes a distinction between the View as a whole and what I call the “Resource View”. What I mean by this is that we separate the concerns of rendering a general Layout from the concern of rendering the Resource (such as a bean object or set of objects) associated with an URL that we are interested in rendering. In practice this means that rendering a Resource in different ways for different clients or different formats (HTML, JSON) becomes very easy, and from the perspective of the implementation outside of templates, almost entirely transparent. In Bowler, you simply extend a “Renderable” Scala trait and pass any number of Resource Model objects into a “render” function, which then takes care of finding the right rendering strategy for resolving output format, templates etc.
A few other frameworks already do these sort of things to some degree, but Bowler takes it a step further by making the recommended programming model even clearer about these things.
Lastly and most obviously: Bowler is built in Scala, which means that developers now have another fully featured web framework they can use to build webapps with in this great language without having to be held back by the restrictions of Java.
JAXenter: What technologies does Bowler build on?
Wille Faler: Bowler is obviously built in Scala, but it is also built on top of Scalatra(for routing and HTTP abstraction) and Scalate for templating. The importance of Scalatra and Scalate cannot really be underestimated in the creation of Bowler, as they are excellent projects that really had already solved a lot of the problems I was looking at very elegantly. Also I think it’s worth singling out guys like Ross A Baker from the Scalatra team and James Strachan from the Scalate team for extra praise, as they have been helpful above and beyond the call of duty when I have had questions or problems. I really do wonder sometimes where they get the sense of urgency and energy from!
JAXenter: What functionality is available in the current release?
Wille Faler: The 0.1 release of Bowler is quite a fully featured web framework and probably contains most of the basics that you would expect from a web framework, but perhaps with the occasional gap for edge cases that I’m hoping community feedback and coming releases will solve.
To mention a few of the features, Bowler has:
– Advanced URL routing (courtesy of Scalatra)
– Templating (courtesy of Scalate)
– “JSON API for free”: if you follow the default programming model set out,
emitting your View Model as JSON instead of HTML is as simple as setting the
“Accept” HTTP Header to “application/json” on the request.
– Composable Layouts
– Hooks in to make multi-device support simple: you can switch layouts and other UI elements based on creating various LayoutFilters, such as choosing a Layout based on User-Agent or other factors.
– Transparent mapping from HTTP Requests to user defined “bean” objects.
– Enforcement of RESTful principles (related to the previous point): only POST & PUT requests can create new “bean”-type objects unless developers explicitly mark these types as “Transient” or otherwise work around this.
– Though built around RESTful principles, it is also entirely possible to test Bowler apps completely outside a web container – ease and quickness of unit-testing is something I have felt very strongly about for a very long time.
Further, one of the aims is to give developers sensible defaults: I think most developers will probably never want to touch the default settings. BUT, if for some reason someone doesn’t like the current rendering mechanism, or doesn’t like the validation framework, they can quite easily switch those out with their own implementation.
JAXenter: What functionality do you envision offering, for the 1.0 release?
Wille Faler: The core framework of Bowler is already relatively fully featured, so I think the core will be mostly about improving what is already there: filling in the gaps, omissions and edge cases, cleaning up and stabilising the API’s, improve any areas that aren’t yet entirely optimal, like making UI re-use even easier and using more idiomatic Scala constructs where it isn’t already in place and where it doesn’t impede ease of use and understanding.
I also see a lot of functionality for a 1.0 release that can be added in additional optional modules/libraries, though I’m quite adamant about doing this as just that, extension modules, so users can pick and choose rather than be dictated to. Ideally I’d like to keep the core very focused on providing a fully featured web framework, but not really have an opinion on implementation technologies for other tiers, such as persistence.
In terms of obvious add-ons/extension modules/libraries, there
are lots of ideas kicking about in my head:
– Persistence utilities to tie Bowler together with JPA, Hibernate and Squeryl apps.
– Form generation and validation based on case class structure and metadata.
– Creating SBT custom processors to automate boiler plate tasks, generate template apps and models (scaffolding type stuff).