Rethink Web Apps in the light of Generics

The following is some musings on Templates and generics. I am not advocating programming this way, just trying to think through these issues in a framework I’ve used before.

The Struts framework dominated web application development in the Java world until the introduction of Java Server Faces. Since Java 1.4 and earlier provide great introspection capabilities and no generics, Struts did heavy runtime introspection to initialize the application and interpret URLS into the paths of the Java classes that should process them. The heart of form processing in Struts is the Action and ActionForm classes. Bascially, struts uses property names to map HTML parameters to bean ‘set’ methods. These can be nested. For instance

orderForm.billingAddress.phoneNumber.areaCode=415

would map to

OrderForm form = session.getBean(“order”);

form.getAddress().getBillingAddress().getPhoneNumber().setAreaCode(“415″)

albeit executed via reflection. Once the form object is populated it is passed to an Action Object. The Action object is an instance of the Flyweight Design Pattern. A Single Action instance can process all of the forms submitted at a time. Note that an Action object is not a singleton: Two instances of the same subclass of Action can be instantiated and have state assigned from the configuration file. They are only “Stateless” with regard to the HttpRequest, HttpResponse, and HttpSessions. Here is the API:

public class ExampleAction extends Action
{

public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception{}

}

The ActionMapping allows you to get specifics about how the action was configured. Mostly it is used to figure out where to go next. The Action form is either down-cast to the correct type (throwing an exception if it is the wrong type) or ignored if there is no submitted data. The mapping class contains a list of forwards. These forwards are kept in a map. The action is going to return a forward configured like this:

return mapping.findForward("success");

We have here several instances of Runtime processing about decisions that could be made at compile time. The code that makes these decisions could be optimized by the compiler. Let’s start with the mapping. A map lookup based on a string is fairly expensive: Either has the string and do a hash-table lookup, or do a series of string compares. Really, what we want is code like:

template <typename Mapping, typename Form>

ActionForward execute(Form form, Mapping map, HttpRequest req, HttResponse resp) {

return map.forwardSuccess;

}

The java Bean API is based on a Java d design decision that everything class type variable a reference. To ensure that you don’t get a Null pointer, you have to fetch something through a ‘get’ method that often acts as a Lazy accessor. This is not necessary for most uses. C++ has the alternative of objects owning the objects they create. Thus the map object, even if created on the stack, can own the forward object. To transform the above in C++, it would be more like:

ActionForward& execute(Form& form, Mapping& map, HttpRequest& req, HttResponse& resp) {

return map.forwardSuccess;

}

The ‘&’ ensures that there is no copying of the objects through the function call. Because the map and returned action forward object both live outside the scope of this function, you can return a reference to the forward. This is true even if the map was originally created on the stack. We’ll come back to that in a little bit.

One task that actions often have to perform is validate a form an return to the previous screen if the form is invalid. In our above code, the logic would be:

ActionForward& execute(Form& form, Mapping& map, HttpRequest& req, HttResponse& resp) {

if (form.isValid() ){

return map.forwardSuccess;

} else {

return map.forwardPrevious;

}

Note that with templates, you could go crazy and have the forward and previous actions, as well as the isValid function name all passed in as template parameters. This would be the ulitmate in flexibility. The question here is the middle ground of settling on an acceptable implied interface.

Let’s take the case of the bean setters being called.

orderForm.billingAddress.phoneNumber.areaCode=415

Code like this is usually generated from a struts tag embedded inside a JSP. Here, code generation (JSP compilation) is generating late bound code. Even without the Generics capabilities of Java 1.5 and later, this can be bypassed, and in fact “pure” jsp processing does that by doinbg the bean API translation in line. However, struts does not have access to the JSP grammer and could not define rules for translation at that point. It only had the weaker rules of the JSP tag API, and thus had to be content with run time binding.

When the servlet API calls the struts servlet onPost method, the struts servel iterates through all of the parameters performs a binding on each one. The cope of the Form is defined by the action mapping that thje JSP refers to in the <FORM> tag. The code in the JSP is something like this:

<form action=”myurl.com/struts/thisform/sumbit.do”>

<input type=”text” name=”billingAddress.phoneNumber.areaCode”>

The URL will be translated to the mapping in the struts config file (minus the .do). The form object is a Bean, usually Session scoped, defined in the same file. Once that is resolved, the rest of the lookup is done using a util function for properties. To convert this to Template style, the first lookup would have to remain the same. URLS can be either absolute or relative. However, we can use functors for the second part: Validating and setting property values. We know what values will be used on a given page. A functor can handle the validation and the setting.
Map <string, string> properties;

Map <string, string>:: data_type data;

Map <string, string>:: iterator_type iterator;

for(iterator = properties.begin(); iterator != properties.end() iterator++){

data = *iterator;

propName,propValue in request

try{

mapping.propertyMap.get(data.first).set(form,data.second));

}catch(ActionException& ae){

actionErrors.add(ae);

}

}

Some people question the efficiency of using Exceptions for handling code of this type. I’ve addressed that in an earlier blog post. Basically, entering a try block generated by g++ is free. The only cost is when the exception is thrown: A new object has to be created and the stack unwound to the point where that exception is handled. The cheapest way to write this code would be to return an error code from action errors, but that propertyMap.get(“”).set(form,””). But then the setter has no way to customize the error message. We could pass back a string or null to signify error or success, but now we are already allocating objects, and adding in an additional test done for every success condition.

If we were to peek beneath the covers of struts into how the code was written for the ActionMapping we would see something like:

getAction().execute(request, response, form,this);

This is where the template parameter comes into play:

template<typename Form, typename Action> ActionMapping : public Mapping{

Mapping(Action& action){

}

process(HttpRequest req HttpResponse resp){

action.execute(request, response, getForm(req),this);

}

}

We still need to descend from a common Mapping baseclass so that the Action and Mapping classes don’t have a circular dependency. But now we have type safety in the call into the Action. Also, the construction of the mapping depends on a specific class. Initializing this code now has to be done in C++. Both the Mapping and the Action objects should be scoped global to the application. The Form can either be request or session scoped. Thus the construction of this complex set of relationships will require a lot of thought.

This article could go on and on. I’m going to add one more related concept and then declare victory and post it.

The difference between a Form object and the domain model is that the form object shuld be able to work with half formed, invalid data. Quite often, the form will contain builders for objects in the domain model. A Trivial example is a social security number. This is of the format 000-11-2222. Often, the UI will put each of these fields into a separate text box. The builder will then accept each field, validate their length and that it only has didgits, and produce a SocialSecurityNumber.

One way that this could be made generic is to provide a Template class that represents a validator for a regular expression. The SocialSecurity Number would be one instance, but each of the sub fields would be instances as well. Someething like this:

typedef ValidatedString<”\d\d\d-\d\d-\d\d\d\d> SocialSecurityNumber;

This is not valid C++, as the string cannot be passed to a type. It might be OK in Java where Regular Expressions are processed at run time.

Doing Unspeakable things with Templates

The C++ Template language is Turing complete.  That means it should easily be able to build an Acceptor for a Regular expression.  Yes, this is headed where you think it is.  Get out while you still can.

Still with me?  Too bad for you:

 #include <string>

using std::string;

namespace acceptor{

template <typename Next> class Expression{
public:
static bool accept(string& s){
return Next::accept(s, s.begin());
}
};

class EndType {
public:
static bool accept(string& s, string::iterator itr){
return(itr == s.end());
}
};

class NoOp {
public:
static bool accept(string& s, string::iterator itr){
return true;
}
};

template <char valid,typename Next = NoOp > class Char{
public:
static bool accept(string& s, string::iterator  itr){
return (valid == *itr) && Next::accept(s,++itr);
}
};

template <char first,char last,typename Next = NoOp >
class RangeAcceptor{
public:
static bool accept(string& s, string::iterator itr){
return ((*itr >= first)
&& (*itr <= last)
&& Next::accept(s,++itr));
}
};

template <int count, typename Acceptor ,typename Next = NoOp>
class Count{
public:
static bool accept(string& s, string::iterator itr){
int i;
for ( i = 0; i < count ; ++i){
if (Acceptor::accept(s,itr)){
++itr;
}else{
return false;
}
}
return Next::accept(s, itr);
}
};

template <typename First, typename Second >
class Or {
public:
static bool accept(string& s, string::iterator itr){
if ( First::accept(s,itr)) {
return true;
} else {
return Second::accept(s,itr);
}
}
};

template <typename First, typename Second >
class And {
public:
static bool accept(string& s, string::iterator itr){
return (First::accept(s,itr) && Second::accept(s,itr));
}
};

template <typename Next = NoOp >
class Digit: public RangeAcceptor<’0′,’9′,Next>{};

template <typename Next>
class LowerLetter : public RangeAcceptor<’a’,’z’,Next>{};

template <typename Next>
class UpperLetter : public RangeAcceptor<’A’,’Z’,Next>{};

template <typename Next = NoOp >
class Letter : public Or < LowerLetter<NoOp> , UpperLetter<NoOp> > {};
};

How would you use this?

 void testDigit(){
Expression<
Digit <
Digit <
Digit <
Char  < ‘-’ ,
Digit <
Digit <
Char  < ‘-’ ,
Digit <
Digit <
Digit <
Digit <
EndType
> > > > > > > > > > > >ssn;

string s(“000-22-9999″);
assertTrue(s, ssn.accept(s));

s = “abcdefghij”;
assertFalse(s, ssn.accept(s));
};

Not shown:  Implementation of the Kleene Star, as that would require a writing a greedy algorithm, something I have no desire to do right now.

Dynamic Frequency Assignment Protocol

A book about the war in Iraq had an brief passage about an Army Unit that needed to stop, dismount, and reset their frequency because they were getting stepped on by a marine Corp unit using the same freq. The Marines were in contact and were not about to change Frequencies. This lead me to thinking about a way to solve this problem via network protocols and public/private key exchanges.

Each unit has a radio. These radios already can encrypt traffic and frequency hop. In fact, frequency hopping would have prevented the unit from getting stepped on. But let’s assume that freq hopping is out of the picture for now. Instead, we want to set up a protocol where a unit can reassemble on the network without having to expose itself and meet face to face.

1. Each machine would get a private key. This allows it to be uniquely identified on the network.

2. Each machine gets a list of public keys and their assigned units (a heads up display could then show who was talking, removing the need for “Black 8 this is Black 6 over.”)

3. A set of frequencies would be set aside for meta-data commo. I’ll call this the MDF. The MDF would be shared by all units within a theater of operations, and would be redundant. Just like name servers, a radio would get a list of MDFs to try. Thus four MDFs could be assigned, and four units would get a different MDF to use as it’s primary.

4. The radio would monitor both its main frequencies (the Radios I used when I were could monitor two, I assume the new ones can do better) and the MDF. MDF traffic would all be binary data. Listening to it would be like listening to a 300baud modem.

5. A “Lost” Unit would broadcast a connection request on the metadata frequency. Any other unit in the area could answer.

6. Higher would send down the new frequency using the lost units public key.

7. The lost unit’s radio would set the new frequency and drive on.

One glaring weakness is that the MDF itself could be jammed. One faulty radio could crap-flood the frequency.

It also adds overhead to the whole system by removing frequencies that could otherwise be used. An optional interactive authentication step could provide for the soldier entering a pin or password if there is some question of the radio being compromised. Two valid response could be provided, one that means , “I’m me” and one that means “I’m me and doing this under duress.”

Note that none of this would prevent manual resets, just provide an additional capability for automated resets.

Of course, this is yet more electronics subject to the beating an infantryman gives it.

Update:  Of course the Military is way ahead of this.

http://en.wikipedia.org/wiki/AN/PRC-148

And

http://en.wikipedia.org/wiki/Joint_Tactical_Radio_System

A new outlook on some old activities

The time from Dec 24th until January 2nd was spent in New Hampshire with my family.  It was a real vacation, something I have not had in a long time.  Aside from the time off, I got outside for a few winter sports:  Cross Country Skiing, Sledding, and Snowshoeing.

Growing up, my family was all about downhill skiing, but the cost, plus the time away from my family meant that I had no drive to go.  Even with all of the great snow this past week.

For cross country, we went out the East Branch of the Pemigewasset  river by Lincol Woods.  The snow was so hard packed that many people were out hiking using just boots and simple crampons.

My folks had picked up a pair of snow shoes.  My wife and I tried them out and I fell instantly in love with the sport.  I have always loved the New England woods, especially the ability to wander aimlessly.  Snowshoeing opens up the woods in winter time.  With the snow covering all the entangling underbrush that hadn’t dies off in the fall, and the metal teeth biting in allowing you to navigate the steepest slope, the woods are open to a degree you don’t find any other time. Yes, snowshoeing is slower than hiking or skiing, but the mobility is amazing.  So now I have to do research to buy myself and my wife a pair.

My Dad has a tractor and an excavator, and I swear he never stops playing on them when we go to NH.  This year, he ignored our entreties not to tear up the meadow and used the excavator to build a sledding run.  The meadow was always a tough sled run, as the long line also was the crest of the hill, and it constantly wanted to throw you off into the flats or the underbrush.  He built a track right down the crest, augmented with a little shovel work.  The packed down snow soon became Ice.  A little Silicone lubricant applied to the bottom of the tubes made for one hell of a fast sled run.