Python Notes

Monday, March 14, 2005

RAD style programming for web apps

It's nearly one month since I posted my last rant here. I was very busy, and working on a lot of different stuff, so I did not really had time to get my hands on code. But the forced rest was good, because it allowed me to take some time to investigate some of the underlying ideas that were bothering for long.

I was a relative early adopter of the then-called event driven programming, when the term was new, and Windows was barely a blip on the radar. My first experiences were with Borland Pascal, and later, with Visual Basic and Delphi. Of the tools of that age, I recall Delphi as being the best. It's design is still underrated; one of the best things about it was the quality of the VCL, a library 'done right' since the first incarnation. Of course, there were rough edges, but considering the maturity of the industry at that stage, it's a great library.

The main innovation brought to the mainstream by both Visual Basic and Delphi was the concept of visual components. I am not going to argue either about quality, or about who did it first. What set them apart was the easy with which a novice programmer could select a ready-made piece of code - a component - and attach code to handle events. That's incredible easy even by todays standards.

Fast forward ten years or so to the web applications age. It's amazing that even today, there's still nothing as easy to use as a Visual Basic component for the Web. (Of course, I am limiting my search to fully compliant web-based tools!). The best explanation that I can come up with is that web development is inherently different from standard GUI development, and so, porting the paradigm is impossible. The main problem sems to be the dogma of separation of presentation & logic. Also, given the fact that a simple component would have to rely on a fragile glue of Javascript, server script code, HTTP intrinsics and DHTML & CSS, it's fairly understandable why it's so hard to do it.

After some thought, I realized that I don't fully buy this explanation. I am beginning to realize how to glue all these pieces together in single framework, in a standard and reusable fashion. I already have some code working, as a proof of concept. The snippet below is a web form which declares a validator, in Python, which is automatically called (via a custom callback mechanism) when the EditBox component loses focus:
def isNotEmpty(result, formName, fieldName, formData, msg=msg):
if formData[fieldName] == '':
result.setWarning(formName, fieldName, msg)
else:
result.clearWarning(formName, fieldName)

class PersonForm(Form):
nome = EditBox(
source='name', caption = u'Name', size = 15,
onblur=BrowserCallback(notEmpty,
msg=u'The name can't be empty!'))
address = EditBox(
source='address', caption = u'Address', size = 60,
onblur=BrowserCallback(notEmpty,
msg=u'The address can't be empty!'))
The PersonForm class generates Web form, and attaches the onblur event to a standard Javascript method that initiates the callback, using an IFrame. The server receives the callback request and dispatches it to the isNotEmpty function, which was registered by BrowserCallback. The callback handler receives a result object, which exposes a simplified server-side API that represents the objects in the client side. The result is renderend as a snippet of Javascript code and sent back to the browser, which executes it to update the form display accordingly. Note that the programmer does not need to know Javascript, or how to write a callback; all the necessary glue is written automatically by the framework.

This is a promising experiment. My intention now is to generalize the callback mechanism, and define a clean API for the components. Separation of presentation and logic is not only possible, but easy to achieve; the code relies on CSS for all visual effects, making it easy to fine tune the details, including the positioning of the elements. I hope that this tool improves my own productivity with web development.