Slots: A Web Framework in 2 Classes

By Dino Fancellu
August 7, 2004

The number of Java web frameworks out there is huge, rivalled only by the bloated nature of many of the frameworks themselves. This is kind of ironic, given that the recent drive behind Java (both the core language and J2EE) has been to simplify it.

Even though some of these frameworks are so huge and unwieldy, people make political/religious oaths of allegiance to them (sometimes through necessity, e.g. the customer demands it, or lack of viable alternatives for the particular problem you're trying to solve). As a result, the frameworks end up more like prisons, where every act is piped through N layers of redirection and filtering, where you find yourself having to hack yourself the kind of workflow that your project in reality needs.

To put it bluntly, I've become pig-sick of these huge framework/religions, where you spend most of your time jumping through fiery hoops, working around bugs, just to get your work done. In an article that I co-wrote a while ago we happened to criticize Struts. Some of the angry feedback suggested that I should put my money where my mouth is and show how I think it should be done, rather than simply dissing other peoples' work, which is easy to do.

So here's Slots. It's by no means intended as a replacement for Struts or WebWork or JSF (etc), but instead is intended to show that it really is possible to produce a web framework that's simple from the ground up. Slots doesn't contain nearly the amount of functionality to be found in these other frameworks, but then functionality or a fat "spec sheet" aren't what Slots is about. Struts in particular is also setting out to solve a different problem, one that I personally don't think exists.

What is Slots?

Slots is a templating framework for servlets and JSP. However, 'framework' isn't entirely accurate, unless you consider 2 class files a framework.

Yes, that's right, the entirety of Slots is 2 class files, the main controller servlet SlotServlet, and an extremely useful wrapper class that calls a page and returns its response in a string, SlotWrapper. The only other file needed is slots-config.properties, which defines your templates and page definitions.

Slots was created in order to give developers an easy to understand, easy to learn templating framework, where you don't have to buy several books, get a mortgage on a second brain, nor swear allegiance to a new coding religion. All the code is open source, and given the size of the code base (around 350 lines), only takes a few minutes to get your head around. I assume you understand basic Servlets and JSP, nothing else is needed. There is no concept of deploy, no need to stop/start the JSP engine, simply alter your JSPs or slots-config files, then refresh your browser. This leads to very rapid iterations, no 60 second deploys.

In terms of what it does, Slots is probably closest in concept to Tiles. But again, it isn't intended to be a replacement. Instead, I want Slots to stand by its own merits; to demonstrate that it's actually possible to follow simple design principles when designing a generic web framework.

There are some basic principles driving the design of Slots:

1. For the core framework at least, less is more.

2. A natural way of building your own webapp is to extend the framework. So that should be the simplest thing to do, not the most complex.

2. For anyone wanting to extend the framework, resorting to Java programming is not an act of evil. That is to say, you don't have to create many layers of XML just to add a textfield or do some customisation.

3. Build on top of JSP but don't reinvent it. The world doesn't need another fancy templating mechanism; JSP will do just fine.

Hopefully you'll find that Slots is very easy to use, very easy to debug, very easy to change. You are in charge, not the framework; you won't be a slave to my idea of what your project should be like.

Why Doesn't Slots do Very Much?

Slots makes use of functionality that's already there in JSP; there didn't seem to be any point reinventing any of it.

For example, Slots does templating but in a very vanilla JSP manner. There's no need to add extra taglibs, no need to throw away JSP in favour of something else. It can be used by anyone who understands request.getAttribute(). There's no mysterious black box, no levels upon levels of source to dig through in order to debug the actions of the SlotServlet.

As for new features, I could add more functionality to the framework; and then keep on adding. But I don't really want it to get as big and ugly as some other frameworks. It does what it does, and in a way that anyone's brain can comprehend in a few minutes. I don't want to sacrifice that for the sake of new features: sometimes, less is more.

Where to From Here?

Slots Central, a page of Slots-related resources.

Related Articles:

Generate enterprise applications with JGenerator

Swinglets goes Open-Source [press release]

Message Forum:

I'd welcome your feedback, especially if you have any ideas about how to improve Slots, make it simpler, or add stuff without compromising its core simplicity. I'm really not interested in getting into a slanging match about Slots versus other frameworks; if it's a feature war, Slots will lose; but I'm comfortable with that!

Post a new message

Great idea
R Sharp robin.sharp@javelinsoft.com
Questions/Observations
John Bridges John.Bridges@ikkyou.com
Re: Questions/Observations
Dino Fancellu 
swinglets ....
Renosh renosh.vasudevan@gmail.com
Swinglets: JSP
Dino 
Swinglets
Anil Y anil.y@ocimumbio.com
Development of Swinglets has stopped
Dino 

Post a new message

<< Back to Design

<< Back to Software Reality