I write a lot of web applications, but I don't like JavaScript. Too many
applications made today are forced to be browser applications when the
functionality clearly indicates a desktop solution.
There, I said it. I never did much client-server programming so I can't really
be accused of holding on to something who's time has come. There are certainly
many benefits to web applications too, not the least of which is ease of
deployment to the end user. However, after doing several applications that
overused javascript in the worst ways (Like implementing a QuickSort that could
sort table rows using the DHTML object model) I became very tired of
Javascript, with its many idiosyncrisies and fragile nature. I have been
accused lately of going too far down this anti-script path. In ASP.NET, its
just too easy to set items to auto post back and create the desired effects
from within the safe and familiar environment of my favored, garbage collected,
strongly typed and compiled language of choice.
To be fair, I view the fact Microsoft has put a great deal of effort into
making it easy to deploy WinForms applications via the AppUpdater block and
features in VS.NET 2005 as support for my opinions. Web Services + Thick Client
+ Easy Deployment = Best of many worlds. Even Sun had it figured out several
years ago when the came up with Java WebStart: why not run a desktop app via a
shortcut to a web site that checks for updated versions of the code it needs to
run? Of course, writing desktop apps in Java is less fun than covering yourself
with papercuts and jumping into a pool filled with ice-cold lemon juice, so JWS
does them little good.
My point in all of this rant was that .NET is wonderfully extensible in many
different ways. It was suggested to me that server-side code could be written
to generate some basic and common client side Javascript actions, such as
making it so that a radio button list could hide or show an ASP:Panel depending
on its selection, without postbacks. Seems simple enough, but if designed
properly it could be the first step towards bigger and better things.
Without doing any code experimentation yet, I can think of 3 ways I might set
out to do this:
Ineritance
Inherit from controls already in .NET to add the functionality desired. For
example, create a custom RadioButtonList that is smart enough to generate
client side events to perform some action. The problem with this is that I want
to leave inheritance as a last result. I may purchase some 3rd party component
that I wish to add this functionality to, meaning extending the base controls
may not be an option.
Builder
Some type of builder pattern may be appropriate, where the attributes needed to
provide the desired run-time functionality are added via logic encapsulated in
Builder classes that operate on otherwise vanilla ASP.NET web controls. The
downside of this solution is that it seems like it could be a little more
dran-n-drop than adding a few lines to your code behinds manually.
Custom Control Library
This idea is intriguing, although probably slightly overengineering a simple
problem. We could probably create a library that would allow us to write ASP
code such as the following:
<library:ToggleVisibleRunat="server"
ShowValue="Yes"
HideValue="No"
Target="loginPanel"
Event="IndexChanged"
ID="Clientaction1"
NAME="Clientaction1">
<asp:RadioButtonList
Runat="server"
ID="showLogin"
AutoPostBack="False">
<asp:ListItem>Yes</asp:ListItem>
<asp:ListItem>No</asp:ListItem>
</asp:RadioButtonList>
</library:ToggleVisible>
<asp:Panel
Runat="server"
ID="loginPanel">
... other stuff here ...
</asp:Panel>
With this type of metaphor, we could also allow dran-n-drop coding, and allow
the values such as "ShowVaule" and "Target" to be configured via the Properties
Grid and .NET's most excellent design-time support. I will think about this,
and come back after some experimentation.