I recently implemented a newsletter subscription
form in ASP.NET (2.0) for the CGIAR
Secretariat on behalf of CGNET. This is
the second project I’ve done in ASP.NET for CGIAR. I’ve never considered myself
a skilled ASP developer and like many, picked up my ASP skills based on code
I’d seen on the
intertubes and via transfer from related
languages. In other words, prior to this project, I was a somewhat capable
ASP spaghetti
coder.
Tired of producing mediocre code and eager to learn what this whole .Net
thing was all about, I decided to invest some time learning how to write better
ASP and take advantage of as many features of .Net as I could. Armed with two
really good books on the subject (Beginning
ASP.NET 3.5 in C# and VB and Programming ASP.NET 3.5, 4th
Edition), I learned a lot about the .Net revolution and in the end I
significantly improved the quality of my code.
.Net borrows heavily from other MVC-like frameworks.
I was surprised by the number of similarities between the ASP.NET-way
of doing things and the Fusebox-way
of doing things. The rest of this post examines some of these
similarities and other aspects of working with ASP.NET. This is mostly an
examination of ASP.NET from a (PHP) Fusebox developers point of view.
The Project
The CGIAR Secretariat is responsible for www.cgiar.org. The CGIAR Newsroom is one of the primary
sections of their web site. It includes an aggregate RSS news feed of
all news items coming out of many of the CGIAR centers. Since many people still
are unaware of the advantages of RSS, the CGIAR Secretariat asked if we could
set up a system that would allow people to subscribe to the feed via
email. Specifically, the system we set up allows people to subscribe and/or
unsubscribe via cgiar.org which then automatically sends periodic emails of
recently added news items (as they’re added, of course).
The Bottom Line
As an “experienced” web application developer I very much appreciated the
ASP.NET-way of doing things. There was nothing in this project that ASP.NET
wasn’t able to handle elegantly and more or less efficiently. The project
consisted of implementing the following features:
- A public subscribe
and unsubscribe form with CAPTCHA
- A nightly script that produces a notification email, with alternate views
(plain text and html), consisting of news items that had not been sent in
prior emails (which implies keeping track of what’s been sent and what
hasn’t)
A password protected administration interface
The entire project was completed in about 80 hours (including an initial
version of the administration interface which was later tabled).
If given the choice of doing the same project in PHP Fusebox, assuming I had
the same knowledge and experience with PHP that I had with ASP when I started,
would I have chosen PHP Fusebox over ASP.NET? Maybe…
Master Pages
One of the goals of any application framework is to maximize code reuse (and
conversely, minimize code duplication). Functions (methods) are one example of
how this is accomplished, but when it comes to the presentation level,
developers often find they need a more powerful programming model. Both ASP.NET
and Fusebox (and many other web application frameworks) provide tools
capable of complete solutions. In ASP.NET, a Master Page
is a template for all the pages of a site although its functionality goes
beyond a simple templating engine. Master Pages also let you define “behaviors”
common to all pages, similar, somewhat, to the Fusebox 3 fbx_Settings
file or the Fusebox 4 fusebox.init file.
A powerful templating engine will frequently go beyond “one layer” and allow
the developer to subdivide sections of the Master to be handled by other parts
of the application. ASP.NET offers this functionality directly and at least one project I’ve worked on in Fusebox had the
same functionality. I found a few opportunities to use this feature on this
project.
Fusebox does not offer a templating engine out of the box, but you can
easily create much of this capability in Fusebox 4 (and to some degree in
Fusebox 3) using Content Variables and a “layout” circuit. Most projects I work
on offer some such circuit.
In the end I got a lot of milage out of Master Pages for this project and
hope to be able to use them in future projects for CGIAR.
Postback
By default, every ASP.NET page contains a form that executes on the server. The
value of the “action” attribute for the form is the current file. Microsoft has
termed this approach “postback” because you post the form back to the same
document that created it. In some respects this is similar to the Fusebox
implementation of the Front Controller design
pattern, where every request is for the same server-side script (e.g.:
/index.php) followed by a Query String containing directions on what
files, functions, and procedures to execute.
ASP.NET offers the developer server-side elements knows as panels. Panels are
“controls” (elements?) that contain other controls. By setting the visible
property of a panel you can control whether or not its contents are visible on
the page. For the CGIAR project mentioned above, I used this technique to
display either the subscription form or the “thank you” message following a
successful subscription. I suppose that, if each ASP.NET page is the equivalent
of a Fusebox circuit, that each panel could be the equivalent of a
Fuseaction. You would simply set the display for all for all of them to false
(except the default fuseaction ;-) ) and then display them as needed. Coming
from Fusebox, I found the concept very easy to grasp.
Code-behind
Microsoft made an attempt to separate application logic from presentation with
.Net. In my opinion, they succeeded.
In order to minimize the amount of raw code found in HTML, .Net provides
something known as “code-behind” pages, which are essentially includes with the
same name as the file they are attached to. The idea is that your application
code goes in the code-behind page and if you need to modify the presentation
(the HTML) from within the application code, you do so by referencing elements
in your HTML page via their ID attribute (this is an oversimplification but
summarizes the approach).
Fusebox, on the other hand, tries to separate code by prefixing file names
with one of dsp_, qry_, act_ (and sometimes lyt_).
- qry_ files contain datasource queries and (usually) return some
sort of object or array echoed to the browser by a dsp_ file.
- act_ files are for those instances in which you need process data
prior to executing a query or echoing to the browser.
- lyt_ files are, in essence, the same as Master Pages in
ASP.NET.
In ASP.NET the “HTML” files contain a LOT of .Net namespaced elements. This
means the files can be completely valid XHTML (with the single, notable
exception of the Processing Instructions found at the top of each page). The
benefit is that these files are suddenly very portable and can be consumed by
any system capable of reading XML.
If you wanted to reproduce this ASP.NET functionality in Fusebox, you would
need to write a plug-in that parses the dsp_ files looking for <fbx:
elements and responds accordingly. You could put all of your code in
act_ files which would essentially turn them into code-behind files. Now
there’s potential open source time sucker!
Data Controls
As one would expect, the data
controls are very complete, but figuring out how to do something like
nesting GridViews was not obvious and were it not for a Nested
GridView walk-through article on MSDN, I never would have been able to
figure out how to do it. Furthermore, I’m not convinced executing sql on EVERY
ROW of a record set is really a good idea (the authors of the walk-through
admit this is not the best approach, but only as it concerns caching…).
Much of the CGIAR Newsroom
revolves around their RSS feed (which is a compilation of feeds from all of the
CGIAR Centers). ASP.NET 2.0 and above include controls for using XML as a data
source and thus facilitating the display of XML data in a web page.
Unfortunately, in version 2.0 of .Net (and possibly higher), using XML as a
data source only allows you to display the data. It does
not allow you to use the built-in INSERT, UPDATE, and DELETE
features of the GridView control. There are work-arounds for
implementing this missing functionality but I have to wonder if you save
any time hacking in the functionality vs. building the entire administration
interface the “old” way (which can be done pretty quickly using XSLT). By my
estimates, it’s a draw, at best.
ASP.NET Advantages
For my needs, web controls, validation in particular, significantly reduce
web application development time. I simply cannot express how much I like the
validation controls and WISH PHP had something similar!
IntelliSense greatly
speeds up coding - Microsoft offers several free (web)
application development tools that work quite well and are more than
adequate for the projects I usually work on and many include IntelliSense.
I don’t think I could have completed this project as quickly without
IntelliSense.
ASP.NET Ambiguities and Disadvantages
Since no language is free of sin, here is my list of things that got the
best of me while working on this project:
- web.config cannot be part of code repository since it is machine
dependent. If application configuration options are so different between
deployment environments, then maybe the author of the application should
consider using a different development environment. I would prefer to have
the application configuration code right in the application tucked into
code that “sniffs” the environment and configures accordingly. This makes
for MUCH more portable code.
- .Net developers frequently publish their source code, but it usually
needs to be compiled so unless you’re into that or have the time to learn
how to do it (and do it right), you won’t find the same kind of huge Open
Source community of code that exists for PHP
- ASP.NET 2.0 includes some Authentication and Authorization controls, but
like most stuff like this, you have to do things the ASP.NET-way or you
can’t use these controls. In other words, there is no (apparent) way to
retrofit these controls onto existing authentication mechanisms. In the end
this is probably a good thing since most existing authentication methods
are not very secure, but in the real world most clients simply are not
willing to put money into changing existing systems unless you can clearly
demonstrate they are broken.
- One of the main complaints of Fusebox 4 was the XML files. Rather than
being used simply for configuration, you could easily add business logic to
them. More than one programmer has asked herself: “Why bother with XML to
represent classes? Why not just use classes directly?” I must say, when
programming in ASP.NET, I often feel like I’m simply setting application
configuration parameters which, for anything but the most basic
interactions, makes programming harder (and possibly more time-consuming)
rather than easier (and faster) since you have to have a clear
understanding of what state the application is in at the exact point where
your code appears. This can be harder than it seems.
In the end, if I had to do it all over again (and had the choice), I would
probably stick with PHP Fusebox but I’m grateful I had the opportunity to
improve my knowledge ASP.NET and I wish the CGIAR Secretariat the best with
their new system.
Additional Reading and Links
Convert
ASP.NET applications into real MVC frameworks
Fusebox
Basics
Comparison
of Web Application Frameworks
