Have seen a few play apps' source and it feels like massive boilerplate and leaky promise/future/async crud everywhere.
Lets take this:
https://github.com/guardian/frontend/blob/master/article/app/controllers/ArticleController.scala
case class ArticlePage(article: Article, storyPackage: List[Trail], edition: String)
object ArticleController extends Controller with Logging {
def render(path: String) = Action { implicit request =>
val promiseOfArticle = Akka.future(lookup(path))
Async {
promiseOfArticle.map(_.map { renderArticle }.getOrElse { NotFound })
}
}
private def lookup(path: String)(implicit request: RequestHeader): Option[ArticlePage] = suppressApi404 {
// .. stuff omitted
}
private def renderArticle(model: ArticlePage)(implicit request: RequestHeader): Result = // .. omitted
}
Let's look at that render
method. What does it do? It's pretty hard to tell, even with a lot of the code removed. It's trying to render an article.
If we just wrote some vanilla code to do that, it would be:
def render(path:String) = {
renderArticle(lookup(path).getOrElse(NotFound))
}
So what's all that other stuff? We've got all the buzzwords covered:
- promise
- future
- async
Why is this here? Several of this apps controllers have this exact structure. Shouldn't this concern be separated somehow? Even the Action
DSL method
that starts this off sticks out like a sort thumb. This method is all unnecessary complexity. To figure out what it does, I have to know what futures
and promises are, and what Async
does, but moreover, almost none of this method's source is specific to the business logic being performed. Why?
Let's see some more boilerplate:
implicit request
- why do I have to type this in every controller? Shouldn't every controller have a request without me typing code?!views.html.article
- I really have to tell theArticleController
to use HTML and to use thearticle
view?Cached
- why is this in the controller? This should be a separate concern.
I realize that some of this might be because of Scala's type system, but it just feels like we've taken the same boilerplate from XML or Annotations and made it code and somehow that makes it OK.
I hated repeating myself and telling the framework what it should've already known in XML, XDoclet, and annotations. I don't like it any better in code.
Isn't an
object
just a container for functions? Why do I need indirection between a URL and "what to do"? I find it very confusing in Java web apps where the urls and controller names/methods don't match up, especially when there is no real reason they should not. aGET
to a route like/people
should, without explicit configuration, be serviced by, for example,PeopleController.get
.As to "initializing a bunch of state", this can actually make the underlying API more fluent, and git rid of all the
implicit
cruft. At a simplistic level:So, I guess my beef is with API design - I'm in a controller - it's a special type of class/object, so there are huge advantages to making things easier. If the purpose of the class is to service an HTTP request, why not make it as simple as possible for me to access the raw request, headers, params, etc?