19 October 2006
Fortitude Forms Need A Handler Action
One thing which bothers me about how Fortitude Forms operates is that it needs an action. The reason for this is simple:
- Fortitude has a controller, and a controller must delegate logic somewhere
- The HTML form needs somewhere to submit
But what’s unfortunate is that all the updating logic is buried in Fortitude’s controls. Any validation can only sensibly be placed in an explicit action, not just a looping action. The action is really only necessary to instantiate a form, or to unserialize a served form and run it.
Fortitude’s application controller is fairly basic. A full-featured but generic controller hides away in the bowels of fortitude, with just a few line wrapper class to specialize the controller to a particular module. It is certainly possible to write a reusable “unserialize/run” action. What I am struggling with is how to handle the initialization of the form.
It could remain a discrete action: The user clicks a link which would render a form. That triggers ?action=LoadDocument&id=825, and the LoadDocument action procures data and initiates a form. The form, internally, sets its action to the generic postback action. Finally, in the case of a captured event, the Fortitude synchronization code would fork a call to the original controller with its appropriate action.
It would probably be a change for the better. But before it’s implemented, the synchronization code will have to learn to defer event-handling until all data is synchronized. DocumentController’s save cannot be called until tbxDocument has the updated value, after all. It’s a problem that needs fixed anyway, but by giving up the manual Form-handling code, the most common workaround is lost.
It should be indicative that if all of this becomes so, then the code and scope are both finally factored properly. And when that day arises, the control’s can learn to be Ajax aware and usually avoid the entirety of the synchronization issue.