Bowler Interview

New Web Framework Builds on Scalatra and Scalate

Jessica Thornsby
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.

The best example of this in practice is how Bowler out of the
box is able to render JSON instead of HTML with zero extra
development effort simply by having the client pass a HTTP “Accept”
header with the value “application/json” on the Request – I think
this is a killer feature for JavaScript heavy webapps if serverside
work does not have to be duplicated to serve JSON that is consumed
by JavaScript or potentially other clients.

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)
– Validation
– Localisation
– 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).

Author
Comments
comments powered by Disqus