2013-01-30

Minimum viable web framework

In some projects I've been working on, there's a small part of common code and thinking that one could call a minimum viable web framework (well, technically, it's a library and not a framework, but I digress). There's absolutely nothing new in it, and if you've ever done even one Servlet app, you know it already. I see that as an advantage.

My minimum viable web framework consists of 8 lines of code and one principle. The code (quoted below) is a static method (on some utility class) that takes a path to which to forward a request, the request and response objects, and then a vararg list of alternating names and values to put as request attributes. The principle is: if something produces any HTML, then that's all that thing does (inverted: if you don't produce HTML, you don't produce HTML). Anything that produces HTML (in my cases, JSPs) only reads values prepared for it from the request attributes (and if you have something that produces some output that isn't HTML, then it's by definition a special case and is exempt from this rule). It's OK to have lists and other simple data structures as request attributes, and it's OK to use simple looping constructs (e.g. a JSTL core forEach) in the rendering, but you can't do things like calling methods from there.

public static void forward(String path, HttpServletRequest request, HttpServletResponse response, Object... attributes)
throws ServletException, IOException 
{
        for(int i=0; i<attributes.length; i+=2) {
                request.setAttribute((String)attributes[i], attributes[i+1]);
        }
        request.getRequestDispatcher(path).forward(request, response);
}

Together, the code and the principle give a simple way of keeping application code and page formatting separate, and I've been quite happy with it in my projects. There's a lot of things missing that you might expect a framework to provide (e.g. input validation or data access). I see those as nice to have and that the only essential part of a web framework is facilitating the separation of logic and rendering.

So, what do you think - is this web framework both minimal and viable? If it's not minimal - how can we minimise it? If it's not viable, then what's missing? And last but not least: does it zoom?

5 comments:

  1. Wait what, is that a method on the servlet? and you prep your data in the onGet/Post methods, then call this method to dispatch to the presentation? If so, then it zooms :)

    ReplyDelete
  2. The method is a Utility class. Things that do logic do logic in doFoo, and then call forward() to dispatch to the presentation.

    ReplyDelete
  3. Yes ofc the method should go into the "Framework" utility class, I was confused, all is good now. It zooms :)
    If I created BloatedFramework I'd include some central sanity checking method for letting JSPs set headers (specifically cache). Since a web framework shouldn't talk HTML, it should talk HTTP. But then again, that is probably a special case.

    ReplyDelete
  4. I'd say cache headers should go in the logic (i.e. servlets), as it's the logic that knows how long the data that's formatted by the presentation should be considered fresh.

    ReplyDelete
  5. I really should go to sleep now since I'm talking rubbish, you are 100% right. If I ever write a web-app again I'll use this and nothing else.

    ReplyDelete

Note: only a member of this blog may post a comment.