Tuesday 7 June 2011

ASP from a Python/Zope perspective.

I have recently changed jobs (hence the lack of posts recently), switching from 3 years of dedicated open source Python development, mainly in the Zopes and Plone, to Microsoft ASP.NET. I thought that a post is some of my observations on the transition would be interesting.

ASP.NET has a very different ethos to any of the Python frameworks I have used in the past. It is far more frontend orientated, with most of the functionality tied in some way to the HTML page. The typical way to construct a page in ASP is to embed (pre-built) ASP html controls into a page’s markup (using XML). Examples of the controls are textbox, label, image, table etc. There are python frameworks that do this, it’s not that unusual, but ASP takes it to a whole new level.

One of the most useful functions of a control is that it is capable of automatically maintaining its own state throughout multiple POSTS and reloads. Fill in a text box and on page reload you text will still be there without you having to code anything.

Control can also disseminate datasources, such as SQL, Arrays or even web services. A table control can be linked to a SQL datasource which will then render as a HTML table of data without writing a single line of actual code.

The power of these controls far surpasses those available in python frameworks, especially if you start buying commercial controls. A table control can by default render a HTML table capable of allowing end user to filter, group, sort and export the data. Nice ajax updates are also relatively simply. Link the table control to an ajax manager control and any functions that would previously have been a POST get transformed to ajax. As a nice example you can generate graphs from a datasource control using the charting controls in about 2 minutes.

So where is the down side, there has to be one right? Yes there is. The main problem with ASP.NET is actually where Python shines: in the elegant control of information from source to page. ASP may well be able to do very clever things quickly and simply on the front end, but controlling the data through a full lifecycle can be a pain as soon if you want the least bit of customisation.

How do you check for specific errors that occur when fetching data on one of those fancy automated datasources? - You have to subscribe to its events. What if I want to change how and when the data is fetched? – You have to hope the control exposes the functionality you want and documents it. In comparison Python frameworks almost universally provide a very consistent model for the organisation of data, from your SQLAlchemy model, to your queries to your View and data marshalling up to the template. It can be done nicely is ASP but it takes more time and design to get it correct.

Python’s organisational architecture is far superior to ASP’s and only getting better with clean and simple design patters (decorators), WSGI, Clean object models, Views, Routes etc. ASP’s out of the box front end elements are equally as superior to anything Python frameworks has to offer, the likes of Deform are a nice clean, Pythonic start but don’t get anywhere near to power of their ASP equivalents.

No comments:

Post a Comment