D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Viewing the Presentation Layer as an "Application"

Wednesday, July 11, 2007 10:01 PM

I'm coming up to the midway point of my "How I am becoming a better developer in 6 months.", and I have a bit of catching up to do. Oddly enough, what I should have done is add in an area called "Get my passion back", although in April I don't think I would have posted "quit my job and go independent" as one of the goals.

Anyway, I had a goal of reading a couple of tech books a month, but I'm just now starting to sink my teeth into some relevent geek-reading over the last month and a half.

One of the books I'm reading is Rocky's Pro C# 2005 Business Objects book, which is a must read btw whether you want to implement his CSLA framework or not. Rocky presents an excellent how-to guide for creating a reusable framework, and seeing the process of developing one is definately worthwhile on its own. The company I'm contracted to currently is using CSLA for their application development, and its quite powerful stuff.

One thing that really struck me in his book was the separation between Presentation and UI layers. From a web application standpoint, this concept couldn't be more relevant. With the mass adoption of AJAX, the demand for richer client interaction, and the quality and depth of controls like Infragistics who rely on client-side script, really thinking through HOW the user will interact with your webpage should be paramount in the design.

Another discussion that grows from this is where the lines of separation should be between the UI and the Presentation layers. .NET enables us to register script blocks, startup-scripts, and assign JavaScript directly to attributes of controls all within code-behind...but does it make sense to merge the two layers or keep them entirely separate, allowing for the UI to deal solely with server-side items (the .vb or .cs) and the presentation to deal with the rendered control's interaction with the user (the .aspx page)?

As an example I'll use the old ClientID issue I posted about before. ASP.NET will automatically create a custom ClientID that is output to the browser to ensure no duplicate control names are generated. This is great for repeater-type controls where you may have 10 instances of FirstnameTextBox, but not so great if you only have one FirstNameTextBox that you want to reference in JavaScript methods on your page.

Now, there are a few ways to deal with this. One is to create a custom class on the server-side that inherits from TextBox but overrides the ClientID to return just the straight ID value that you want. This means that your JavaScript becomes more readable, and you also have better control over the actual ID used since the generated name is a concatenation of sorts including the page name, container name, etc. However, you could easily go down the slippery slope of "Oh...it would be nice if that control had a normal ID...oh and that type of control too...oh and..." and all of a sudden you've overridden the entire toolbox just so you could get to a non-lengthy ID value.

Alternately, you could generate your JavaScript entirely from the code-behind. In this scenario, you don't have to worry about the ClientID because you'll just insert it into the JavaScript that gets written out to the browser anyway. The downside of course is that there's no easy way to write Javascript in the code behind other than writing out text using a string builder or concatenating strings, and then if you need to test the script or make a change it requires a re-compile. Plus it adds extra weight to the class itself, in terms of just amount of text and in extra processing.

But what's the best practice to take though? From a purely architectural view, by generating JavaScript from the code-behind file, aren't we merging what should be considered two separate layers? And what about the maintainability aspect of having JavaScript generated on the server but also written to the aspx page itself, coordinating any cross-use between two "tiers"? Alternately, placing all JavaScript creation in the code behind allows for less hard-coding of values between the two layers, and removes having to alter the underlying functionality of the base classes (i.e. like overriding the ClientID property of a control)

Don't get me wrong...I don't think that either option is necessarily better than the other...both have their merits (one of my tricks is to create a method that would take in a control and output a JavaScript method to set focus to that control on the postback, and setting attributes for things like onClick and such is very easy and clean to do in the code behind).

I think the bigger issue is that we as web developers need to really consider the idea of the Presentation as a separate layer, and how they plays into developing the entire User Experience (I'm not using UI here as its a separate layer that makes up the UE). JavaScript has always been looked at as this odd, bastardized second cousin of "true" development languages, and yet we're more reliant on it now than ever before. How we architect the interfaces for users needs to evolve beyond "we'll just throw some JavaScript on the page to do that"...it needs to be more intentional than that, and with the same diligence used to create a datamodel or a logical design.

All this from literally a few pages of the first chapter of Rocky's book...like I said, regardless if you're going to implement CSLA or not, its a fantastic read.



No comments posted yet.

Post a comment