<%@ page language="java" %> <%@ page import="com.maff.forum.*,com.maff.forum.jsp.*" %> <%@ page session="false" %> Slots Developer Guide - Software Reality <%@ include file="/include/body.txt" %> <%@ include file="/design/table-top.txt" %> <%@ include file="/design/title.txt" %> <%@ include file="/include/navbar.txt" %> <%@ include file="/include/storytable-top.txt" %> Slots Web Framework <%@ include file="/include/storytable-mid.txt" %>

Slots Developer Guide

<< Slots Central

 

Developer Guide

This is a guide to the inner workings of the Slots framework, all 2 classes of it.

As for all Servlets the first thing in SlotServlet to be called is :


public void init(ServletConfig config) throws ServletException {
    super.init(config);
    ServletContext context = config.getServletContext();
    String realpath = context.getRealPath(slot_config);
    slotsConfig = new File(realpath); 
    if (!slotsConfig.exists())
    {
        System.out.println("** Config file does not exist at " + realpath);
    }
}

Here we get the File for the location of the slot-config.properties file, currently located in /WEB-INF. We don't put it in the class path, as changing it would make the JSP engine restart, which just slows things down.

Next we make doGet/doPost defer to protected void processRequest(HttpServletRequest request, HttpServletResponse response) to handle both types of request.

Firstly we get the pathinfo for this request, which is where we expect to get the slots page we want to serve up, or if that doesn't exist we get it the servletpath as the Slots servlet can also be invoked by asking for a page that ends in .slot. This gets automatically mapped to .jsp. So for example test1.jsp could be called like this:

/webcontext/slot/test1.jsp

or

/webcontext/test1.slot

The next important thing it does is to loadProperties(). This is only done if slots-config file has been changed since last time it was loaded.

We then check the internal slots cache for derived slots for this page. If none are found we call resolveEntry on this page and store the results back to the cache for next time.

We then create a SlotWrapper for this request, which allows us to call another page and retrieve the response as a String. Very useful for later as you will see.

We then iterate on all non base slots for this entry, and either get the static String defined or call the page for this slot with the SlotWrapper, then store this string back to the request attributes for this slot.

Having done this, if we haven't overridden slots_content ourselves, we call the page with the SlotWrapper and set the slots_content attribute.

Finally we get the base file defined and forward on this request to this base file, along with all the filled-in attributes.

Apart from the recursive inner workings of resolveEntry, where the 'clever' bits of the code live, that's that.

If there is something you don't like about Slots, something you think is missing, just add it. It is yours. You are not here to serve the framework, to spend time jumping through fiery hoops for the 10% of functionality you want. It is here to serve you. If your system needs more from Slots, change Slots, not your system. Never let your framework become more important than your business.

 

<< Slots Central

<< Software Reality Front Page

 

<%@ include file="/include/storytable-bot.txt" %> <%-- navbar2 --%> <%@ include file="/design/table-bot.txt" %>