Experiencing a bottleneck with your Object Relational Mappers, Services, Middleware, Database, or whatever? Then Memcached it!

Memcached was intially developed for LiveJournal by Danga Interactive in 2003, and is used by many large sites (YouTube, Amazon, Twitter, to name a few). Today, you can find a Memcached library for all your favourite languages (here's the list).

Now; cache testing is tough period, and testing Memcached (which is accessed through a telnet client) is even more difficult - it's fair to mention that there are a large number of wrappers for Memcached outside the .NET world, but I couldn't find one for that met my needs.

So... I wrote my own. :)

Introducing Memcached on Powershell

Sample usage and output

Loading the script (source can be found here)

Checking Memcached stats on an empty instance

Checking Memcached stats after items have been added to the cache

Clearing all Memcached items

Checking Memcached stats on a cleared instance

If your test obsessed then you might be interested in the Memcached tests.

As always feel free to contribute, view, or download the source here.

How it works

If you have a project on GitHub or Google Code, you can retrieve your project details.

Single project host retrieval URI:

http://adam.kahtava.com/services/open-source/projects/{project-host}.{xml|json}?user={username}

Multiple project host retrieval URI:

http://adam.kahtava.com/services/open-source/projects.{xml|json}?project-host:username={project-host1:username1,project-host2:username2}

Example, requesting projects from Google Code in XML format:

Request: http://adam.kahtava.com/services/open-source/projects/googlecode.xml?user=adam.kahtava.com

Response:

Example, requesting projects from GitHub in JSON format:

Request: http://adam.kahtava.com/services/open-source/projects/github.json?user=adamdotcom

Response:

Example, requesting projects from both GitHub and Google Code in a single request in XML form:

Request: http://adam.kahtava.com/services/open-source/projects.xml?project-host:username=github:adamdotcom,googlecode:adam.kahtava.com

Response:

And Now What?

View my sidebar widget that uses this service to display the latest updates from my source code repositories here.

Contribute, view, or download this openly available source code here.

Contribute, view, or download the script here: Mailer.ps1

How to hack an Anti CRSF Token from PowerShell

To run this script:

1. Download the script
2. Run PowerShell
3. Load the script: .\Automated-AntiCSRF-Authentication-Script.ps1
4. Start sending spam-spam-spam: PS > spam-adamdotcom

Here's the output as seen on my machine:

This example uses a derivation of the .NET Framework's Web Client class but with Cookies enabled, so it depends on the AdamDotCom.Common.Service.dll assembly (browse the source here). This dependency can be automatically resolved by issuing the download-client function that's also found within the PowerShell script.

Contribute, view, or download the openly available script here: Automated-AntiCSRF-Authentication-Script.ps1

Why use an Anti CRSF Token?

An overly simple example: If I didn't use an Anti Forgery Token on my contact page (see the source code: View or Controller), a Spammer could POST data directly against my contact form and potentially drown me with spam.

Here's a hypothetical form created by an evil Spammer. This form is hosted on http://spammer.com (not my site):

<form action="http://adam.kahtava.com/contact/send" method="POST">
  <input name="fromName" type="text" value="Johnathon Fink" />
  <input name="fromAddress" type="text" value="prancesw@rmcres.com" />
  <input name="subject" type="text" value="Call for your diploma now" />
  <textarea name="body">Is your lack of a degree...</textarea>
  ...
</form>

Again, note that the form action contains a reference to my site (even though it is hosted on another site).

Now, imagine this was a form prompting a user for their username and password. These credentials could be maliciously stored while the user successfully authenticates and is then redirected to the site they thought they were visiting - the way phishing usually works.

After adding an Anti CRSF Token to my contact form, a Spammer can't access my form remotely (at least not without the token). My contact form with it's Anti CRSF Token:

<form action="/contact/send" method="post" name="contact">
  <input name="__RequestVerificationToken" type="hidden" value="0sAqY1ZKb+Qia4..." />
  <input name="fromName" ...

Note the presence of the RequestVerificationToken.

Said Spammer, can't abuse my form without including the unique token. Technically speaking the Spammer can still abuse my form, but he now needs to:

• Request (GET) my contact form
• Parse out the Anti CRSF Token
• POST their spam into my contact form along with the token

This is pretty easy to do if you have an implementation of a HTTP Client library that supports cookies.

How to hack an Anti CRSF Token protected form

Using an extended instance of .NETs Web Client here's how our Spammer could circumvent my Anti CRSF Token.

The Spamming script by that wascaly Spammer:

// create a new HTTP Web Client that supports cookies
var webClient = new WebClientWithCookies();

//download my contact page containing the Anti CRSF Token
webClient = webClient.DownloadData("http://adam.kahtava.com/contact");

//parse out the Anti CRSF Token
var antiCrsfToken = RegexUtilities.GetTokenString(
                      new Regex("__RequestVerificationToken=(?<CRSF_Token>[^;]+)")
                      .Match(webClient.ResponseHeaders["Set-Cookie"]), "CRSF_Token");

//now the Spammer can drown me in spam-spam-spam
// by scraping my Anti CRSF Token and posting it into my form
webClient.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
byte[] response = webClient.UploadData("http://adam.kahtava.com/contact/send", "POST",
                            Encoding.UTF8.GetBytes(
                              "__RequestVerificationToken=" + antiCrsfToken +
                              "&fromName=\"Johnathon Fink\"" +
                              "&fromAddress=\"prancesw@rmcres.com\"" +
                              "&subject=\"Call for your diploma now\"" +
                              "&body=\"Is your lack of a degree...\""));

The Spammer is back at their old tricks sending me more Spam. ARGH!

What's the use of an Anti CRSF Token?

Anti CRSF Tokens help prevent phishing attacks. They aren't meant to prevent spammers or Dr Robotnik and his robots (or web scrapers) from running automated scripts against your web application. Keep in mind, that if your site suffers from other XSS vulnerabilities (where the privacy of your cookies or sessions are compromised) then Anti CRSF Tokens don't work at all.

Read more about how Anti CRSF Tokens work here: Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper or learn more about Cross-Site Request Forgery at: The Cross-Site Request Forgery (CSRF/XSRF) FAQ.

The "Validation of viewstate MAC failed" error only occurred when a page contained an HTML form element that made use of MVC's AntiForgeryToken. The quick fix was to delete my __RequestVerificationToken cookie, but the error would rear its ugly head the minute I touched my assemblies. The long term solution was to add a machineKey element to my Web.config file - asking visitors to delete a specific cookies when visiting my site was not a viable option.

How I fixed the "Validation of viewstate MAC failed" error on Shared Hosting:

1. I used the <machineKey> Generator Tool to generate a machine key
2. I added the machineKey element to my Web.config file

My Web.config now looks similar to this:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <machineKey validationKey="..." decryptionKey="..." validation="SHA1" />

Anyhow, I hope this post helps anyone else that's encountering this error.

Oh wait, here's the error in its entirety for The Google Machine's crawlers:

Server Error in '/' Application.

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

If you're reading this from an RSS feed, then the changes looks like this:

These new sections make use of the services I created earlier - my resume content is pulled directly from LinkedIn via my Resume service, the Reading Lists and Reviews are being pulled from Amazon via my Amazon service, and I'm still working on a personalized greeting module which will make use of my Whois service.

Now, when I update my resume on LinkedIn, add a new item to my Amazon wishlist, or write a new Review on Amazon the content is updated within this site and indexed by the Google.

It took longer than expected to get these new pages up and running - mostly due to a couple false starts. You see, I'm running this site on Windows shared hosting which unfortunately doesn't give me many options - sure, sure, I could purchase another hosting account, but developers are like freak'n MAcGyver we like working within ridiculous constraints. It's all about the challenge! Anyways, I first tried using Ruby on Rails on shared hosting (fail), then tried using PHP on Trax (fail), and finally reverted to ASP.NET MVC. While ASP.NET MVC is heads and tails more fun than Web Forms / Classic ASP.NET, the impedance mismatch between strongly typed objects and web languages (JavaScript, CSS, XHTML) is still annoying. Thankfully the MVC Contrib project solves some of these pains, however it can't solve them all.

My next steps with this site are to: finish the greeting module, update the layout (drop the WordPress theme), and finish a Github / Google Code repo widget (kind of like this one) for the sidebar.

Contribute, view, or download the openly available source code here.

The Enhanced Whois web service lets me know where my visitor are geographically located, provides filtering capabilities, and can act on referrals. This will allow me (or you) to personalize site greetings, hide my email address (or content) based on the visitor, and provide a unique personal experience. Alternately I can use this service as a classic Whois service.

How it works.

We're not anonymous on the internet and IP addresses are what uniquely defines your internet existence. Whois services let us determine the registrant of internet resources.

Using my Whois service you can:

View your enhanced whois record.

By the visitor's IP address (your IP) URI:

http://adam.kahtava.com/services/whois/enhanced.{xml|json}

Example:

Request: http://adam.kahtava.com/services/whois/enhanced.xml

Response (using my IP):

<WhoisEnhancedRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <City>Calgary</City>
  <Country>Canada</Country>
  <FilterMatches i:nil="true"/>
  <FriendlyMatches i:nil="true"/>
  <IsFilterMatch>false</IsFilterMatch>
  <IsFriendly>false</IsFriendly>
  <Organization>Shaw Communications Inc.</Organization>
  <StateProvince>AB</StateProvince>
</WhoisEnhancedRecord>

By the visitor's IP address specifying a referrer, and a filter URI:

http://adam.kahtava.com/services/whois/enhanced.{xml|json}?filters={filters,filters,...}&referrer={referrer}

Example:

Request: http://adam.kahtava.com/services/whois/enhanced/xml?filters=CA&referrer=Twitter

Response (from an IP owned by Google, with a filter for California, and a referrer of Twitter specified):

<WhoisEnhancedRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <City>Mountain View</City>
  <Country>United states</Country>
  <FilterMatches>
    <string>StateProvince</string>
  </FilterMatches>
  <FriendlyMatches>
    <string>google</string>
    <string>twitter</string>
  </FriendlyMatches>
  <IsFilterMatch>true</IsFilterMatch>
  <IsFriendly>true</IsFriendly>
  <Organization>Google Inc.</Organization>
  <StateProvince>CA</StateProvince>
</WhoisEnhancedRecord>

View your classic Whois record.

By the visitor's IP address (your IP) URI:

http://adam.kahtava.com/services/whois.{xml|json}

Example:

Request: http://adam.kahtava.com/services/whois.xml

<WhoisRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <DomainName>68.146.10.100</DomainName>
  <RegistryData>
  <AbuseContact> ... </AbuseContact>
  <AdministrativeContact i:nil="true"/>
  <BillingContact i:nil="true"/>
  <CreatedDate>2002-06-03</CreatedDate>
  <RawText> ... </RawText>
  <Registrant>
    <Address>Suite 800630 - 3rd Ave. SW</Address>
    <City>Calgary</City>
    <Country>CA</Country>
    <Name>Shaw Communications Inc.</Name>
    <PostalCode>T2P-4L4</PostalCode>
    <StateProv>AB</StateProv>
  </Registrant>
  ...
</WhoisRecord>

So... why is this useful?

This is the first step for this site's personalization - if I know where the user came from, where the user is geographically located, and have the capabilities to filter their Whois responses, then I can tailor my content to the user. For example: if someone from Google landed on my site I could mention that I'd love to work there and provide my email address and phone number, similarly if someone from Calgary landed on my site I could provide my public calendar of local events. The possibilities are endless.

This service will be wrapped by a JavaScript widget that will take care of the asynchronous service polling, but that sounds like another post.

Contribute, view, or download the openly available source code here.

How it works.

If you have a resume on LinkedIn and you've added services@adamdotcom.com as a contact then you can:

View your resume - retrieve your Resume by first and last name.

By first and last name URI:

http://adam.kahtava.com/services/resume/linkedin/{firstName-lastName}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/resume/linkedin/adam-kahtava.xml

Response:

<Resume xmlns="http://adam.kahtava.com/services/resume" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Educations>
    <Education>
      <Certificate>Computer Programming and Analysis</Certificate>
      <Institute>Seneca College of Applied Arts and Technology</Institute>
    </Education>
    <Education>
      <Certificate>Bachelor of Science (Honours), Computer Science</Certificate>
      <Institute>Trent University</Institute>
    </Education>
  </Educations>
  <Positions>
    <Position>
      <Company>Corbis ...

Wow that was exciting, so now what?

Well.. Head on over to my resume page. My resume is being pulled from LinkedIn through this very service.

Contribute, view, or download the openly available source code here.

My online portfolio is increasingly scattered through the internet (reviews and wishlist are on Amazon, source code on github / Google Projects, resume on LinkedIn, and so on). I've been working on a couple services that will eventually pull my portfolio together while keeping a single point of reference, and... I'm sharing these services.

Introducing my Amazon Web Service.

How it works.

Basically if you have a Wishlist or a Review list on Amazon you can:

Discover your profile - retrieve your ListId (for WishLists) or CustomerId (for Reviews):

Discovery URI:

http://adam.kahtava.com/services/amazon/discover/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/discover/user/adam-kahtava.xml

Response:

<Profile xmlns="http://adam.kahtava.com/services/amazon" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <CustomerId>A2JM0EQJELFL69</CustomerId>
  <ListId>3JU6ASKNUS7B8</ListId>
</Profile>

View your Reviews - retrieve your Reviews by username or Amazon CustomerId.

By customerId URI:

http://adam.kahtava.com/services/amazon/reviews/id/{customerId}.{xml|json}

By username URI:

http://adam.kahtava.com/services/amazon/reviews/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/reviews/id/A2JM0EQJELFL69.xml

Response:

<Reviews xmlns="http://adam.kahtava.com/services/amazon" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Review>
    <ASIN>0321125215</ASIN>
    <Authors>Eric Evans</Authors>
    <AuthorsMLA>Evans Eric.</AuthorsMLA>
    <Content>Through this book Evan's ...

View your Wishlist - view your Wishlist by username or Amazon ListId.

By listId URI:

http://adam.kahtava.com/services/amazon/wishlist/id/{listId}.{xml|json}

By username URI:

http://adam.kahtava.com/services/amazon/wishlist/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/wishlist/user/adam-kahtava.json

Response:

[{"ASIN":"0471467413","Authors":"Mostafa Abd-El-Barr, Hesham El-Rewini", ...

So now what?

Head on over to my Reviews and Reading List pages. These pages make use of the data from this service. I should also mention that, this service was built on a previous iteration of my Amazon Web Service (How To Display Your Amazon Reviews and Wish List Using Amazon’s Web Services).

Contribute, view, or download the openly available source code here.

Don't write frameworks for dummies. [Frameworks designed by organizations] that assume some developers are not smart enough ... are likely to fail because they underestimate the difficulty of ... development. ... This attitude also poisons the relationship between [the developers and framework designer]. - Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

Evans goes on to make the point that there's a fine line between designing for dummies, and providing useful encapsulation / abstraction. I found this advice interesting because I had been wrestling with whether the ASP.NET AJAX Framework is for Dummies.

Today Wikipedia lists 80 different web frameworks that use MVC - with Java and PHP topping the list for the languages with the most MVC web frameworks. MVC enforces a separation of responsibilities: Markup / CSS / JavaScript, Domain Objects / Containers, and Actions / Controls are broken up into their respective directories. In addition MVC provides the ability to test most of your code and is more intuitive with how the web works (REST like, based on URIs, plays nicer with the browser, and not dependent on POST backs).

Finding good resources specifically for ASP.NET MVC is impossible at this time, but the books covering Ruby on Rails (RoR) are invaluable. RoR has been around since 2005, it uses the same basic MVC approach, similar routing, similar control structure, has a mature community, a large collection of plug-ins, and well established tools (anyone claiming that ASP.NET MVC can't do what WebForms can, should look to Rails as an example). Gasp! It's almost like ASP.NET MVC has copied Rails!! :)

Anyhow; the more I learn about Rails and Ruby, the more I realized that the communities like RoR (SmallTalk, and even some of the PHP world) are years ahead of my native .NET community. At this point I'm considering abandoning .NET in favour of Ruby / Rails / RSpec or at least Merb / Ruby / RSpec. In the future when ASP.NET MVC and IronRuby are more mature or when the corporate world starts using ASP.NET MVC (read never ever!) or when I'm approached to work on an ASP.NET MVC project I might move back into ASP.NET. In the mean time I'd like to contribute to IronRuby as I work towards jumping my current technology stack. I've armed myself with Textmate (the E Text Editor) and a MacBook Pro is in my future. I'll get back to you on how this goes. :)

As developers, limiting ourselves to a single metaphor, framework, or programming language is a liability to our career. In order to remain employable and engaged with our work, we need to understand the higher level concepts surrounding our chosen development arena - if you're working in the webspace this means knowing CSS, JavaScript, HTML, and more than one server-side language. Then beyond technologies and languages we should be looking at transcending principals like design patterns, and good design practices.

identifying with anything so strongly that it starts to give you emotional reaction is really bad. You never know when your language is going to be obsolete or ... your favorite framework is going to be replaced. ... I would love to see everybody learn a bunch of languages because it does make you a better programmer. ... Most people will never switch languages. - Steve Yegge, stackoverflow podcast #25 

If you've ever landed on Amazon then you're probably familiar with their reviews and wish lists. Amazon provides access to these items (and many-many more) through their extensive web services - the Amazon web services can be complex and overwhelming when all you want is a review list and a single user specific wish list. For this site I wanted to pull in my reviews and wish list - displaying them alongside my blog. It's fair to note, that user reviews are available via an RSS feed (but this feed doesn't include all the details I wanted) and the wish list page still doesn't provide an RSS feed. So a custom Amazon web service request was in order.

Let me try to make this story short.

If you want to request your reviews and your wish list you need the following:

• An Amazon Account: http://www.amazon.com/gp/css/homepage.html with at least a wish list or a review.
• An Amazon Associates tag: https://affiliate-program.amazon.com/gp/associates/join/ (this will be your AssociatesTag).
• An Amazon Web Service (AWS) access key: http://aws.amazon.com/ (this will be your AWSAccessKey).

Once you have a wish list or review, you then need to:

• Get your CustomerId for the reviews. I found my CustomerId by navigating to my reviews (http://www.amazon.com/gp/cdp/member-reviews/A2JM0EQJELFL69/) then pulling out 'A2JM0EQJELFL69' (the last element of the url).
• Get your ListId for your wish list.  I found my ListId by navigating to my wishlist (http://www.amazon.com/gp/registry/registry.html/?id=3JU6ASKNUS7B8) then pulling out '3JU6ASKNUS7B8' (the identifier after id= from the url).

Once you've collected all those bits, you need to:

• Checkout and download the source code for the project and build the assembly or download the pre-compiled assembly.
• Add the assembly reference to your project (remember, I'm assuming you're using .NET).
• Make a call to the application which will generate XML files containing your respective reviews and wish list.

Setting up the call would look something like this:

IAmazonRequest amazonRequest = new AmazonRequest() {
 AssociateTag = "adamkahtavaap-20",
  AWSAccessKeyId = "1MRF________MR2",
  CustomerId = "A2JM0EQJELFL69",
  ListId = "3JU6ASKNUS7B8"
};

IFileParameters fileParameters = new FileParameters() {
  ProductFileNameAndPath = @"Products.xml",
  ReviewFileNameAndPath = @"Reviews.xml",
  ErrorFileNameAndPath = @"Errors.xml"
 };

IAmazonApplication amazonApplication = new AmazonApplication(amazonRequest, fileParameters);

amazonApplication.Save();

And Viola!

If you'd like to provide some design guidance, fix a bug, or request a feature, then visit (or join) the project on Google Code.

Alternatively, you might also be interested in the LINQ To Amazon source featured in the book LINQ in Action.

Microsoft is looking to make jQuery part of their official development platform ... jQuery will be distributed with Visual Studio
- jQuery, Microsoft, and Nokia

Other links of interest:

• Scott Hanselman: jQuery to ship with ASP.NET MVC and Visual Studio
• Scott Guthrie: jQuery and Microsoft

I was completely blindsided by this decision.

What's really wrong with ASP.NET AJAX?

• It doesn't plan for performance from day one
• It treats AJAX as a classic computer science problem
• It tries to turn JavaScript into a classical language which works against JavaScript's dynamic, prototypical nature
• It feels like a framework that was written for dummies (Don't Write Frameworks For Dummies)

A Case Study: Why Plaxo.com Almost Failed

In the video: High-performance JavaScript: Why Everything You've Been Taught is Wrong (YUI Theater) Joseph Smarr discusses the challenges and lessons learned while developing Plaxo.com. While developing this AJAX centric application, the Plaxo team decided to include everything they could think of into their application. They created a framework to treat JavaScript as a classical language, they gave priority to features over performance, and... the project ALMOST FAILED. They were able to salvage their application by diverting their development efforts, making performance one of their top priorities, by unlearning everything they'd been taught about classical applications (instead embracing JavaScript), jettisoning unneeded framework bloat, and more.

Some of the points made in this video were:

• Plan for performance from day one
• AJAX is not a classic problem
• JavaScript is not a classical programming language
• User experience and a responsive application can make or break an application
• Unneeded bloat in a framework, and an obtuse approach to using AJAX (treating AJAX and JavaScript as a classical language or classic computer science problem) has the potential to cripple your application

This Channel 9 video also mirrors these sentiments: Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript

How ASP.NET AJAX Failed: What can we learn from Plaxo?

The way the Plaxo team approached their application development is similar to how the ASP.NET AJAX Framework has been designed. Like Plaxo's initial attempt ASP.NET AJAX attempts to mold JavaScript into a classical language, and attempts to treat JavaScript and AJAX as a classic computer science problem by heaping on more abstractions. Like Plaxo's initial attempt ASP.NET AJAX also gives a low priority to performance. Plaxo was able to change their direction and salvaged their application, but the ASP.NET AJAX Framework is not in a position to make any sweeping changes - ASP.NET AJAX is going down the wrong path and it's too late.

The ASP.NET AJAX Framework is probably another exercise in Framework Architecture (demoware) and a failure in practice. Its lack of use in the wild attests to these shortcomings - contrast the sites using ASP.NET AJAX with the sites using jQuery (Actions Speak Louder Than Words). Furthermore the places that ASP.NET AJAX does thrive (the small internal ASP.NET business apps that need some bling-bling) will also be the areas that Silverlight shines - Silverlight offers a better Microsoft centric programming model (less leaky Win Form / Web Form abstractions) that most Microsoft developers will embrace. Silverlight will probably divert the developers that currently embrace ASP.NET AJAX.

I don't recommend the ASP.NET AJAX Framework and won't be contributing to the AJAX Control Toolkit. My time is better spent elsewhere.

I share their sentiments so I thought I'd post a brief but choppy transcript:

[ASP.NET AJAX] ... does offer some some nice features, they did try to take some of the common pieces of the CLR that [.NET Developers are] used to working with and move that down into a JavaScript library. So you get classes like a WebRequest class that wraps the XMLHttpRequest ... and they have a StringBuilder, and they added methods that we're more accustom with ...

that's wonderful, but I don't find myself needing those extensions all that often. If you want to do strictly client-side programming then something like jQuery offers you a lot more capabilities to do things that you really want to do client-side like sorting and CSS selectors. ... That stuff is easy to do with an Update Panel and ASP.NET, but Update Panels aren't always the best solution to use. ...

the goals with ASP.NET AJAX was to integrate into the ASP.NET server-side model ... that's great for ASP.NET, but it needs more client-side features. ... It works if your thinking from the ASP.NET control perspective, but if you look at it outside the ASP.NET model there are a lot easier ways to do it. ...

ASP.NET AJAX [development] seems to have come to a standstill I'm not seeing a lot of development in that area and the rest of these [AJAX] Frameworks are doing monthly releases. Every month that goes by [the ASP.NET AJAX Framework] falls further and further behind ... it needs to evolve.

Listen to this podcast here: Technology Round Table Podcast #2 - AJAX Frameworks

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

After my first attempt, I concluded that:

1. My JavaScript knowledge was embarrassing
2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
5. Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick="return false;" ..., or <a href="Javascript: do something;" ... are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

• Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
• An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
• Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
• An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
• Node manipulation - creating, swapping, removing elements
• Knowledge of non-obtrusive JavaScript techniques
• Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
• An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
• JavaScript code conventions - naming conventions, statement conventions
• CSS naming conventions
• General DHTML / AJAX techniques - showing and hiding elements
• A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, index.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Interesting observations:

How many applications explicitly state that they use the ASP.NET AJAX Framework?

• 25, this includes sites like DotNetNuke (with a reputation of being slow), view the list here.

How many of these applications are relatively high-traffic?

• None. ZERO!

How many applications explicitly state that they use the YUI library?

• 89, view the list here and here.
  

How many of these applications are relatively high-traffic?

• Quite a few. A couple notable sites: Flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera.

How many applications explicitly state that they use the jQuery AJAX Library?

• 516 and growing, view the list here.
  

How many of these applications are relatively high-traffic?

• Many. A couple notable sites: Twitter, Digg, Dell, Slashdot, BBC, Netflix, Technorati, New York Post.

If no high-traffic application uses the ASP.NET AJAX Framework then why would you? Actions (or lack of action) often speak louder than words, and it appears that the ASP.NET AJAX Framework is not suitable for the real world.

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is an example of a bad part - on the contrast the ASP.NET MVC Framework looks to be a good part.

What's wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can't learn or don't want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community's only real problem is education, so let's ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It's patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages are more expressive than statically typed languages like most of the .NET languages. 

2. The "don't write a line of JavaScript" abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas - depend on a 3rd party (vendors or the ASP.NET AJAX Control Toolkit) and their many authors to write your JavaScript - or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel - the AJAX Control Toolkit blows requires debugging and you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language - if it walks like a duck and quacks like a duck, then... err... could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then there's partial-page rendering and Update Panels which do full page post backs under the guise of AJAX. BAD! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the 'J' in AJAX - 'J' stands for JavaScript (that's GOOD)
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn't widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (as .NET Developers) are going to claim we know AJAX, then let's focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.

Comments like "we recommend that...", "because it makes no sense...", "you must rely on a special method...", "you must understand X,Y,Z to run complex client-side code without writing a single line of JavaScript" were discouraging. Many of the "whys" were left answered and the technical inner workings of the framework often trivialized. Don't get me wrong, writing a book is incredibly time consuming, but if you're an author, presenter or the like, and you don't fully understand something then admit it. Do some research, provide some links, or move on. Consistently making comments like these bring the integrity of the whole text into question.

The ASP.NET AJAX Framework itself is technically flawed, bloated, and almost entirely impractical. I was disappointed with the server-centric approach that both the book and ASP.NET AJAX Framework takes. I was disappointed that the book continually pushed JavaScript under the carpet as magic and at the end of the book I was pleased to see the promise of making "the JavaScript code disappear" never was  fulfilled. JavaScript is the very most important part of AJAX, without the 'J' in AJAX, we're left with nothing - just 'Asynchronous', 'And', heaps of more ugly 'XML'.

When reading this book, take the contents and the ASP.NET AJAX Framework with a grain of salt, if you're really serious about learning AJAX then read JavaScript: The Definitive Guide by David Flanagan.

I typically only contribute positive reviews, but I don't agree with the majority of reviews found on Amazon and hope this review provides some objectivity. I commend the authors on their hard work, I'm probably being too harsh with this review - I know it's tough to write a book, and imagine they made many sacrifices as they worked towards tight deadlines.

View my review on Amazon.

In addition to these issues, here are a couple other considerations when thinking about ASP.NET Themes:

• Themes do not adequately separate the levels of concerns within your application. When using Themes all design related files are baked into the application. From a maintainability standpoint, this doesn't bode well in large web applications. Hosting design related files on a single server or an external Content Delivery Network (CDN) is an effective way for managing site wide UI updates and increasing a sites performance, ASP.NET Themes works against this technique.
• Themes add unneeded complexity by obscuring the real technologies at work (CSS). Everything that ASP.NET Themes offer can be better achieved outside of the ASP.NET Theme Framework. Technologies like Cascading Style Sheets (CSS),  alternate Style Sheets, and JavaScript can achieve more than Themes can provide.
• Themes are a server-side mechanism. Themes become a nuisance in client-side dependent, heavily dynamic, Web 2.0, DHTML, AJAX type web applications.
• Themes discourage developers from learning more about web design and the technologies surrounding it. Themes offer a seemingly simple API, which shelters developers from the complexities of CSS and JavaScript, but sooner or later The Law of Leaky Abstractions comes into play and knowing the fundamentals of these technologies is a necessity.
• Professional web designers don't use ASP.NET Themes, CSS is the language of web designers.

Default Skins on the other hand can be useful for defining consistent CSS hooks into common ASP.NET controls. It's unfortunate that we can't use Skins without Themes.

Related posts:

• The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

I've read this book, re-read it, edited it, and would like to give it away - I was the Technical Editor. The books is like new and (did I mention) it's free!

Contest Rules:

• Updated! Just Leave a comment with a valid email address!

• Post a 500 x 200 pixel image of something you're working on in the comments of this post - this image could be code, web design, or anything work related.
• Include an optional description of your work
• The winner will be chosen April 1st May 1st, they'll be drawn at random, and will be notified through email.
• I pay for shipping.

* I've included a sample entry in the comments. If you're looking for a great free photo editing application then try Paint.net. If you're looking to host your image you might want to consider Flickr or Photobucket.

Good Luck!

The contest has ended, and the winner is..... Andrew Hinde. Nice!

JavaScript is probably the world's most popular and misunderstood programming languages and for good reason.
When a developer claims to know JavaScript this generally equates to one or all of the following:

• "I know what JavaScript is, I can learn JavaScript in 30 minutes"
• "JavaScript is for kids, it's a toy language, it's easy"
• "I just copy and paste my JavaScript snippets / scripts from the internet"
• "JavaScript is just another programming language like C++, C#, VB.NET, or Java"

If thoughts similar to these have crossed your mind when sizing up your JavaScript knowledge, then you probably don't know JavaScript.

I would argue that if you've never programmed in a functional programming language (like: Lisp, Scheme, F#), never read a GOOD book on JavaScript, or never watched a video on JavaScript, then you probably don't understand JavaScript at all. JavaScript is starkly different than any other mainstream programming language.

When it comes to JavaScript, if you don't understand the fundamentals then you're only punishing yourself.

Here are some things every JavaScript developer should probably understand:

• JavaScript, Mocha, LiveScript, JScript, and ECMAScript are all essentially the same.
• JavaScript is a prototypically inherited (prototype-based programming) language which is very different than the classically inherited (class-based programming) languages like C++, Java, and most of the .NET languages - you know the difference between a prototype-based programming and class-based programming language.
• JavaScript is a loosely typed language - you know the difference between strongly-typed programming languages and weak-typed or loosely typed languages.
• JavaScript is a functional lambda language - you understand lambdas and that functions in JavaScript can be lambdas.
• JavaScript functions can be defined inside functions, inside functions, inside functions, and so on - you can demonstrate this.
• JavaScript uses function scope, has no curly brace '{}' block scope - you understand that this is common attribute of most functional programming languages.
• JavaScript has no private, public, protected assessors, no classes, no enums, no structs - you understand that all these language features can be achieved through objects and function closures.
• JavaScript is classless, but instead it uses objects as general containers.
• JavaScript makes use of garbage collection.
• JavaScript uses truthy and falsy values - you understand which values are truth and falsy.
• JavaScript makes use of the 'nan' (not a number) and 'undefined' values - you understand the difference between these values.
• JavaScript has pretty good debuggers - you understand how to debug JavaScript from both IE (link) and Firefox (link).
• You appreciate recursion, and understand that recursion is a useful technique in JavaScript.
• You understand that JavaScript Namespaces should be used - you understand the importance of namespaces, and know how to create one (Namespacing Your JavaScript).
• You know how to avoid the JavaScript pseudo-protocol (<a href="Javascript:alert('hello');"), and appreciate avoiding it.
• You know how to avoid embedding DOM Level 0 JavaScript events (<a onclick=''alert('hello');") in your mark-up / document structure, and appreciate this technique.
• You know that JavaScript can make use of two different event models (event capturing and bubbling), but we should only ever make use of bubbling.
• You understand what JSON is and how it's used.
• You know how to keep you JavaScript, CSS, document structure separate, and appreciate non obtrusive JavaScript.

If any of these points seem foreign, then it may be time to learn JavaScript. With all the hype and buzz around Web 2.0 and AJAX it could be a great way to augment your career while broadening your programming language vocabulary.

Great resources for learning more about JavaScript:

Videos:

• The JavaScript Programming Language: Part 1, Part 2, Part 3, Part 4
• An Inconvenient API: The Theory of the DOM: Part 1, Part 2, Part 3
• Advanced JavaScript: Part 1, Part 2, Part 3
• JavaScript: The Good Stuff: Link
• All these videos are available on the YUI Theater - all the videos are great, watch them all!

Books:

• JavaScript: The Definitive Guide by David Flanagan
• JavaScript: The Good Parts by Douglas Crockford

Links:

• MDC: A re-introduction to JavaScript
• Code Conventions for the JavaScript Programming Language
• JavaScript: The World's Most Misunderstood Programming Language
• What ASP.NET Developers Should Know About JavaScript
• Best Practices: Implementing JavaScript for rich internet applications
• The seven rules of Unobtrusive JavaScript

My highlights:

• The session on Agile Project Planning With User Stories, and Refactoring Automated Unit Tests Using Test Smells and Patterns presented by Gerard Meszaros. I've been on a couple projects that could be characterized as "Bad Agile", so Gerard's presentation hit many chords, one of the comments he made really stuck out. He said something like: "it's not about the Agile process, it's about the results, it's about delivering...don't be dogmatic". Sure it's obvious, but it's nice to hear it from someone else.  I'm currently in the process of purchasing Gerard's book: xUnit Test Patterns: Refactoring Test Code.
• Mock objects with Rhino Mocks was another great session (by Shane Courtrille). I've been using Rhino Mocks for a couple months now, but there's always so much to learn from someone with more experience.

I'm trying to make it a point to attend more of these events in an effort to expand my community.

The Problem / Question:
ASP.NET 2.0 Themes automatically includes all the Style Sheets (.css files) found in the active Theme (App_Theme) directory into the Head of the rendered document. This severely limits the robust CSS language, and works against the last decade of Cascading Style Sheet progress. For more specific details on the problems with ASP.NET 2.0 Themes start reading the articles found here.

A Solution / Work Around:
Add a custom VirtualPathProvider to ignore the Style Sheets (CSS files) found in the App_Theme directory. For more background on this solution see my article and David Ebbo's article titled Overriding ASP.NET combine behavior using a VirtualPathProvider.

An example of the problem:

The directory structure:

Notice all the Style Sheets (.css files), there are more in the Adapters directory too.

Before including the CustomVirtualPathProvider (code provided below) into the project's build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" >
  <head><title>The Problems With Themes and Skins in ASP.NET 2.0</title>
    <link href="App_Themes/Default/CSS/Adapters/ChangePassword.css" type="text/css" rel="stylesheet" /> 

    ... The other 17 externally linked Style Sheets go here, they were removed to improve readability ...

     <link href="App_Themes/Default/CSS/PrinterFriendly.css" type="text/css" rel="stylesheet" />
  </head>
<body>

The Style Sheets are automagically inserted into the Head tag from the active Theme directory. Keep in mind that Internet Explorer has a 30 Style Sheet limitation (see article Q262161).

After including the CustomVirtualPathProvider (code provided below) into the project's build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" > 
  <head><title>The Problems With Themes and Skins in ASP.NET 2.0</title>
  </head>
<body>

Notice the complete lack of Style Sheets - ahhh simplicity is bliss, the very foundations of CSS Zen Enlightenment... :) Now we can manually include our Style Sheets, use Conditional Comments, and so on.

The source code for the CustomVirtualPathProvider provided by David Marzo in C#:

namespace Arfila.Web.Logic {
 
 [AspNetHostingPermission(SecurityAction.Demand,
   Level = AspNetHostingPermissionLevel.Medium)]
 [AspNetHostingPermission(SecurityAction.InheritanceDemand,
   Level = AspNetHostingPermissionLevel.High)]
 public class CustomVirtualPathProvider : VirtualPathProvider {
 
   public static void AppInitialize() {
     HostingEnvironment.RegisterVirtualPathProvider(new CustomVirtualPathProvider());
   }
 
   public CustomVirtualPathProvider() : base() { }
 
   private bool IsThemeDirectory(string virtualPath) {
     String checkPath = VirtualPathUtility.ToAppRelative(virtualPath);
     return checkPath.StartsWith("~/App_Themes/", 
       StringComparison.InvariantCultureIgnoreCase);
   }
 
   public override VirtualDirectory GetDirectory(string virtualDir) {
     if (IsThemeDirectory(virtualDir)) {
       return new ThemeDirectory(Previous.GetDirectory(virtualDir));
     }
     else {
       return Previous.GetDirectory(virtualDir);
     }
   }
 }
 
 [AspNetHostingPermission(SecurityAction.Demand,
   Level = AspNetHostingPermissionLevel.Minimal)]
 [AspNetHostingPermission(SecurityAction.InheritanceDemand,
   Level = AspNetHostingPermissionLevel.Minimal)]
 public class ThemeDirectory : VirtualDirectory {
 
    VirtualDirectory _toFilter;
    private ArrayList _children = new ArrayList();
    private ArrayList _directories = new ArrayList();
    private ArrayList _files = new ArrayList();
 
    public override IEnumerable Children {
      get { return _children; }
    }
 
    public override IEnumerable Directories {
      get { return _directories; }
    }
 
    public override IEnumerable Files {
      get { return _files; }
    }
 
    public ThemeDirectory(VirtualDirectory toFilter) : base(toFilter.VirtualPath) {
      _toFilter = toFilter;
      BuildChild();
    }
 
    private void BuildChild() {
      foreach (VirtualDirectory dirToFilter in _toFilter.Directories) {
        ThemeDirectory themeDir = new ThemeDirectory(dirToFilter);
        _children.Add(themeDir);
        _directories.Add(themeDir);
      }
 
      foreach (VirtualFile fileToFilter in _toFilter.Files) {
        string fileExtension = VirtualPathUtility.GetExtension(fileToFilter.VirtualPath).TrimStart('.');
        if (string.Compare(fileExtension, "css", true) != 0) {
          _children.Add(fileToFilter);
          _files.Add(fileToFilter);
        }
        else {
          //archivo .css no incluir
        }
      }
    }
  }
}

Some of the code has been modified for readability, download the original source code here.

Note: In order to use this VPP you'll have to copy the code above into a new class in your App_Code directory.

Conclusion: This is one of the nicest work arounds or resolution to the issues surrounding ASP.NET 2.0 Themes. It allows us to leverage the power of ASP.NET 2.0 default Skins, allows us to logically group design related resources (Style Sheets, images, default Skins, videos, etc...) in the App_Theme directory, allows us to control the loading order (cascades) of style sheets, allows us to use Conditional Comments, to define Media Types, to override / inherit Styles, and to continue using CSS as it's intended. In addition we can now easily integrate the ASP.NET 2.0 CSS Friendly Control Adapters into our web applications.

Discoveries:

1. Some of the more complex web sites (Amazon and Yahoo!) make use of Style Elements within the Body Element - see the source snippets below.
2. Gecko (Firefox, Flock, Mozilla, etc...) based browsers automatically move Style Elements found within the Body Element into the Head Element and render the page as expected - see the rendered Document Object Model (DOM) image below.
3. Internet Explorer doesn't move the Style Element into the Head Element, but renders the page as expected.
4. Opera... well I wish I knew what Opera did, but the page renders as expected.

Source snippet from Amazon:

</table>
    </td>
  </tr>
</table> 

<style type="text/css">
.lol-hr-center { margin: 5px; border-top-width: 1px;
/* and so on... */
}
</style>

<div id="listoflists_data" style="display:none">
Note how the Style element is located between the <table> and <div> tags.

Source snippet from Yahoo!:

<h4>
<a id="paweather" class="details" href="r/wb/*-http://weather.yahoo.com/forecast/USKS0448_f.html"><span class="icon">Weather <b><strong>51&deg;</strong>F</b></span></a>

<style type="text/css">#patabs #weather .icon{background:url(http://us.i1.yimg.com/us.yimg.com/i/us/we/31/b/26.gif) 3px 2pxno-repeat;}</style>

</h4>
Note how the Style element is located within the <h4> tag.

A snapshot of the Document Object Model (DOM) as seen through Firebug:

Note the highlighted area references the Yahoo! source snippet from above.Â
Conclusion: Although the Style Element within the Body Element compromises the validity of a document, some of the leaders in web design and accessibility use this approach, so it may not be as big a work around or hack.

]]> http://adam.kahtava.com/journal/2007/03/20/in-favor-of-using-style-elements-embedded-style-sheets-style-blocks-style-tags-or-whatever-you-want-to-call-them-inside-the-html-xhtml-body/feed/ http://adam.kahtava.com/journal/2007/03/14/code-camp-in-toronto-are-you-going/ http://adam.kahtava.com/journal/2007/03/14/code-camp-in-toronto-are-you-going/#comments Wed, 14 Mar 2007 22:36:29 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,97a5ffc5-cde1-4572-b91f-0a12108065fb.aspx

So what is Code Camp all about?

A Code Camp must follow these rules:

1. By and For the Developer Community - Code Camps are about the developer community at large. They are meant to be a place for developers to come and learn from their peers. Topics are always based on community interest and never determined by anyone other than the community.
2. Always Free - Code Camps are always free for attendees.
3. Community Developed Material - The success of the Code Camps is that they are based on community content. All content that is delivered is original. All presentation content must be provided completely (including code) without any restriction. If you have content you don't want to share or provide to attendees then the Code Camp is not the place for you.
4. No Fluff _ only Code - Code Camps are about showing the code. Refer to rule #1 if you have any questions on this.
5. Community Ownership - The most important element of the Code Camp is always the developer community. All are welcome to attend and speak and do so without expectation of payment or any other compensation other than their participation in the community.
6. Never occur during work hours - We understand that many times people can't leave work for a day or two to attend training or even seminars. The beauty of the Code Camp is that they always occur on weekends.

Read more here: http://www.torontocodecamp.net/

If your attending then I'll see you there. :)

]]> http://adam.kahtava.com/journal/2007/03/14/code-camp-in-toronto-are-you-going/feed/ http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/ http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/#comments Sun, 25 Feb 2007 15:19:12 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,002ae3f5-6496-4d64-aab8-d3ccf498d7c7.aspx In this post I outline a couple alternate ways of defining the CSS Print Media Type with Themes. ASP.NET 2.0's Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Style Sheets (CSS), but don't fully support CSS - I've listed some "Work Arounds" for a couple design flaws. I don't recommend any of these "Work Arounds" since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
How can I use the CSS Print Media Type with Themes? In the past I've used an External Style Sheet which defined the Print Media Type, but ASP.NET 2.0 omits the Media Type attribute when it automatically includes all my CSS files (from the active Theme directory) into the HTML Head tag.

A Solution / Work Around:
The Print Media Type isn't constrained to External Style Sheets and can be defined in the Style Element, in the @Media rule, and even specified through the @Import rule.

An example of the problem:

The directory structure:

The rendered XHTML:
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>
<link href="App_Themes/Default/PrinterFriendlyStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/StyleSheet.css"
type="text/css" rel="stylesheet" />
</head>
Note each externally linked Style Sheet lacks a media type.

Our desired XHTML (using an Externally Linked Style Sheet and a Print Media Type) would have looked something like this:
<head>
<link href="App_Themes/Default/PrinterFriendlyStyleSheet.css"
type="text/css" rel="stylesheet" media="all" />
<link href="App_Themes/Default/PrinterFriendlyStyleSheet.css"
type="text/css" rel="stylesheet" media="print" />
</head>
Note the Media Type (media="print") in bold.

The solutions:

Option 1. Use the Media Rule (@Media) to define the print Media Type inside an Externally Linked Style Sheet.

An example:
@Media Print {
body {
background-color: #FFFFFF;
}
/*... your CSS here ...*/
#Menu, #AdvertismentContainer {
display: none;
}
#Content {
width: 100%;
}
}
Discussion: This is probably the best alternative to defining the Media Type in an Externally Linked Style Sheet - the other solutions introduce problems of their own.

Option 2. Use the Import Rule (@Import) to load your printer friendly Style Sheet from an alternate location and define a Media Type - this involves removing your printer friendly Style Sheet from the Themes (App_Theme directory).

An example:
@Import url("/AppName/CSS/PrinterFriendlyStyleSheet.css") Print;

Discussion: This solution requires moving our Printer Friendly Style Sheet outside the Theme directory, since Themes don't allow us to exclude a Style Sheet folder (see Excluding a CSS folder for more details). Once we start moving Style Sheets outside the Themes directory we should probably ask ourselves why we're even using Themes, and consider regaining complete control over our CSS by moving all the CSS files outside the Theme directory. At this point we could revert to Externally Linking our Style Sheets where we could define our Media Type attributes. In addition the CSS URL function used in this solution confuses many.

Option 3. Use the Style Element to define a Print Media Type.

An example:
<style type="text/css" media="print">
/*... your CSS here ...*/
</style>

Discussion: This solution doesn't work if the Style Elements are defined in the HTML head (see Using Internal (Embedded) Style Sheets with Themes for more details), you can however move the Style Element into the Body of the document, this compromises the HTML validation, but large e-commerce sites like Amazon and Yahoo! make heavy use of this method.

Option 4. Sub class the HtmlHead class to enumerate through the child controls and add new Meta attributes to the child controls using the HtmlLink class. See my post titled Defining a Media Type(s) for more details.
Discussion: This solution requires a fair amount of work and only solves one of the many problems with Themes, pursuing this solution would probably be a case of not seeing the forest for the trees.

In conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS - in this case how printer friendly (print) CSS Media Types are defined. I wouldn't recommend using Themes on a complex web applications that make heavy use of CSS or AJAX, but for small projects they may be a nice option.

Related links:

• CSS Design: Going to Print
• Printing a Book with CSS: Boom!
• A Print CSS Primer
• CSS Media Types Create Print-Friendly Pages

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/25/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-creating-printer-friendly-pages-defining-a-css-print-media-type-with-css-while-using-themes-work-around-5/feed/ http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/ http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/#comments Mon, 05 Feb 2007 18:44:36 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,c1575144-e460-464d-b993-259ce96135f4.aspx ASP.NET 2.0's Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don't fully support CSS - I've listed some "Work Arounds" for a couple design flaws. I don't recommend any of these "Work Arounds" since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
How can I add Internal (embedded) style sheets (the ones that use the Style element) inside the Head tag when using Master Pages and Themes?  How can I override (overload) External style sheets for local pages or specific Web User Controls?

A Solution / Work Around:

One option is to create an ASP Placeholder (asp:contentplaceholder) in the Master Page's Head tag to add the Style element into the Head of your Web Form (.aspx page). However, this solution doesn't work well when using Themes, since themes automatically include the External style sheets after the Style element - I demonstrate this and provide an alternative solution later on in this post.

The Caveat / Warnings:
In most current-generation browsers the loading order for Internal style sheets, and External style sheets depend on their position in the Head tag. This behavior seems to go against what the W3C intended.

Generally speaking we can say that all the styles will "cascade" into a new "virtual" style sheet by the following rules, where number four has the highest priority:

1. Browser default
2. External style sheet
3. Internal style sheet (inside the <head> tag)
4. Inline style (inside an HTML element)

- Taken from: http://www.w3schools.com/css/css_intro.asp

As I understand and as the w3schools point out (I can't find a reference from the depths of the W3C), Internal style sheets should have a higher priority than External style sheets, unfortunately this isn't the reality. Instead External style sheets and Internal style sheets depend on the loading (cascading) order. An Internal style sheet will only override an External style sheet (in current-generation browsers) if the External style sheet is loaded first. This behavior introduces problems when using an ASP Placeholder because ASP.NET automatically includes the Style Sheets (.css) from the active Theme (App_Theme) directories into the Head tag after the ASP Placeholder's contents have been loaded.

An example of the problem:

The directory structure:

The active Master Page:
<%@ Master Language="C#" EnableTheming="true" AutoEventWireup="true"
CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>

<asp:contentplaceholder id="ContentPlaceHolderHead" runat="server" />

</head>
<body>
<form id="form1" runat="server">

<h1>Hello World!</h1>

</form>
</body>
</html>
Note: the ASP Content Place Holder between the Head tags and "Hello World!" between the H1 tags.

The default Web Form (.aspx page) providing the Content for the Master Page's Content Place Holder:
<%@ Page Language="C#" Theme="Default" MasterPageFile="~/MasterPage.master"
AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Default" %>

<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolderHead" Runat="Server">

<style type="text/css">
H1{
color: red;
}
</style>

</asp:Content>
Note: the Style element between the ASP Content Place Holder tag - H1 should now be colored red.

The contents of StyleSheet.css, the only CSS file in the Active Theme (App_Theme) directory:
H1{
color: blue;
}
Note: H1 should still be red because Internal style sheets are supposed to have priority over External style sheets.

The rendered XHTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>

<style type="text/css">
H1{
color: red;
}
</style>

<link href="App_Themes/Default/StyleSheet.css" type="text/css" rel="stylesheet" />

</head>
<body>
<form name="aspnetForm" method="post" action="Default.aspx" id="aspnetForm">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
</div>

<h1>Hello World!</h1>

</form>
</body>
</html>
Note: the position of the External Style Sheet (the Link element) in relation to the Internal Style Sheet (the Style element) - the Internal style definition (color: red;) precedes the External style definition (color: blue;).

The results in a web browser:

Note: according to the style sheet priorities in the W3C guidelines (see above) "Hello World!" should be colored red not blue - the Internal Style should be applied before the External Style; however, this is not the case.
Conclusion; the ASP Content Place Holder "Work Around" doesn't work well with Themes since ASP.NET automatically includes all the CSS files in the active Theme directory - this behavior disrupts the loading (cascading) orders. This "Work Around" could be useful if you were only using Master Pages or were painfully meticulous with your CSS names and made heavy use of the !important style definition.

Another Solution / Another Work Around:
Define the Style element outside the Head tag, directly within the content of your page.

An example of the Work Around:
The rendered XHTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0</title>
<style type="text/css">
H1{
color: red;
}
</style>
<link href="App_Themes/Default/StyleSheet.css" type="text/css" rel="stylesheet" />
</head>
<body>

<style type="text/css" media="screen">
H1{
color: green;
}
</style>

<form name="aspnetForm" method="post" action="Default.aspx" id="aspnetForm">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
</div>
<h1>Hello World!</h1>
</form>
</body>
</html>
Note: the Style element (color: green;)inside the Body tag.

The results in a web browser:

Note: "Hello World!" is green as expected.
The Pros and Cons to this (the Style element outside the Head tag) approach:
Cons:

1. It's not a recommended best practice, but is used by some of the larger sites like Amazon and Yahoo!
2. It's not valid XHTML (but neither are iframes in XHTML Strict)

Pros:

1. Can use Microsoft's Conditional Comments
2. Can use the CSS @Import rule
3. Can use the CSS @Media rule
4. Can use multiple CSS Media types
5. Can easily use Media-dependent cascades
6. Can easily control the CSS load order (inheritance and cascading)
7. It's fairly intuitive and understandable
8. It's compatible with Revision Control Systems

Conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS. Themes aren't recommended for complex web applications that make heavy use of CSS, but for small projects they may be a nice option.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/05/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-using-internal-embedded-style-sheets-with-themes-work-around-4/feed/ http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/ http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/#comments Sat, 03 Feb 2007 19:30:21 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,003772b4-6ef1-4a6c-ba46-f122c787a052.aspx ASP.NET 2.0's Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don't fully support CSS - I've listed some "Work Arounds" for a couple design flaws. I don't recommend any of these "Work Arounds" since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS selectors like classes or IDs.

The Problem / Question:
Is it possible to define the loading order (cascades) of CSS files while using Themes in ASP.NET 2.0?

The Solutions / Work Arounds:
Order your CSS files alphanumerically - ASP.NET 2.0 parses through the active Theme directory and all sub directories alphanumerically including every CSS file into the HTML head (via an external link) of the rendered page.

An example of the problem (when load order isn't defined).
Note: both examples use the same CSS files, but use different loading orders.

The directory structure and StyleSheets:

The rendered XHTML:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href="App_Themes/Default/Controls/OverloadedUserWebControlStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Controls/ReusedUserWebControlStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/OverloadedStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/ReusedStyleSheet.css"
type="text/css" rel="stylesheet" />
</head>

The results in a web browser:

An example of the problem (when load order has been defined alphanumerically).

The directory structure and StyleSheets:

Note: the use of alphanumeric delimiters preceding the Style Sheet names.

The rendered XHTML:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href="App_Themes/Default/aa_ReusedStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Controls/01_ReusedUserWebControlStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Controls/09_OverloadedUserWebControlStyleSheet.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/zz_OverloadedStyleSheet.css"
type="text/css" rel="stylesheet" />
</head>
Note: the ordering of the CSS files.

The results in a web browser:

Comparing the web browser results:

The Pros and Cons to this approach:

Cons:

1. Being a work around it's not intuitive _ a maintenance programmers nightmare - "I'm familiar with CSS, but how are the Cascading Style Sheets being loaded??"
2. Contributes to a fragile environment - the way ASP.NET parses through the App_Themes directories may change in newer versions of ASP.NET, not to mention changing a filename could have negative side effects on the site's design.

Pros:

1. Allows a load order to be defined
2. Compatible with Revision Control Systems

In conclusion; Themes are a nice addition to ASP.NET, but have some significant design flaws particularly in the way it uses CSS. Themes aren't recommended for complex web applications that make heavy use of CSS, but for small projects they may be a nice option.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2007/02/03/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-the-load-order-cascades-for-css-work-around-3/feed/ http://adam.kahtava.com/journal/2007/01/07/underscore-_-rendering-issues-with-cascading-style-sheets-css-in-internet-explorer-ie-firefox-and-other-browsers/ http://adam.kahtava.com/journal/2007/01/07/underscore-_-rendering-issues-with-cascading-style-sheets-css-in-internet-explorer-ie-firefox-and-other-browsers/#comments Sun, 07 Jan 2007 21:22:46 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,3ac7da1a-d857-4cdf-b81a-e62fe30d6ddd.aspx The World Wide Web Consortium (W3C) Cascading Style Sheets (CSS) 2 specifications introduced the underscore (_) as a valid CSS naming character, this allows CSS selectors like class selectors and ID selectors to be named like:

• ._menu_item_1
• #_menu_item_2
• .menu_item_3
• #menu_item_4

However; rendering inconsistencies remain among most popular browsers when Styles, Classes, or IDs are preceded by the underscore character.

Inconsistencies:

CSS Classes and IDs with an underscore immediately after their respective delimiter ('.' Or '#') are rendered by both Firefox and Opera, but NOT by Internet Explorer.
This CSS example will NOT work in Internet Explorer, but WILL work in Firefox and Opera:

._idTest1{
background-color: red;
}
#_id_Test2{
background-color: red;

Style entries preceded by an underscore are rendered by Internet Explorer (IE 6 & 7), but NOT by Mozilla / Gecko (Firefox) or Opera.

This CSS example will only work in Internet Explorer:

*{
_color: green;
}

This is a documented quirk and bug, see The Underscore Hack and IE Underscore Bug Test for more information.

The Results of our Underscored CSS in Internet Explorer:

The Results of our Underscored CSS in FireFox (rendered the same in Opera):

This CSS quirk came up in an ASP.NET forum, where a poster was having cross browser issues with his menu controls. We discovered that <xhtmlConformance mode="Legacy" /> was defined in his web.config file which caused the ASP.NET Master Page control (ctl00) to be preceded by an underscore (_ctl00) which was preventing the CSS from being rendered in IE.

Related links:
The IE Underscore Bug Test
The original forum thread: menu control in master page does not get styles in ie 6.0.
ScottGu's Blog: Gotcha: Don't use <xhtmlConformance mode="Legacy"/> with ASP.NET AJAX
View the complete source code for my Underscore Test or try it on your favorite browser here.

]]> http://adam.kahtava.com/journal/2007/01/07/underscore-_-rendering-issues-with-cascading-style-sheets-css-in-internet-explorer-ie-firefox-and-other-browsers/feed/ http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/ http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/#comments Sat, 11 Nov 2006 16:34:50 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,63d6c2f3-4cd9-4a7d-ab5a-2796033cb3a1.aspx ASP.NET 2.0's Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don't fully support CSS - I've listed some "Work Arounds" for a couple design flaws. I don't recommend any of these "Work Arounds" since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

The Problem / Question:
Is it possible to define CSS Media types (like media="print") in the HTML Head tag? ASP.NET 2.0 automatically includes all my CSS files (from the active Theme directory) into the HTML Head tag, but Themes don't allow me to specify any CSS Media types.

The Solutions / Work Arounds:
Sub class the HtmlHead class to enumerate through the child controls and add new Meta attributes to the child controls using the HtmlLink class. In order to use multiple Media types you would probably need to use more complex logic and resolve Media types to filenames (i.e. SomeFileName_Print.css could resolve to media="print") - for more information on manipulating the HtmlHead class read Phil Scott's post titled: Accessing the Html Header in ASP.NET 2.0.

An example of the problem:
The HTML source automatically generated by ASP.NET 2.0 Themes (note the lack of media attributes):
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href="App_Themes/Default/HandHeld.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Print.css"
type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Screen.css"
type="text/css" rel="stylesheet" />
</head>

My desired HTML source (note the media attributes in bold):
<head>
<title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
<link href="App_Themes/Default/Default.css"
type="text/css" rel="stylesheet" media="all" />
<link href="App_Themes/Default/HandHeld.css"
type="text/css" rel="stylesheet" media="handheld" />
<link href="App_Themes/Default/Print.css"
type="text/css" rel="stylesheet" media="print" />
<link href="App_Themes/Default/Screen.css"
type="text/css" rel="stylesheet" media="screen" />
</head>

The Pros and Cons of this approach:

Cons:

1. Can't use Microsoft's Conditional Comments
2. Can't use the CSS @Import rule
3. Can't use the CSS @Media rule
4. Can't easily use multiple CSS Media types
5. Can't easily control CSS preferred and alternate style sheets
6. Can't easily control the CSS load order (inheritance and cascading)
7. Contributes to a fragile environment
8. Not intuitive _ a maintenance programmers nightmare - "I know CSS, but Where are the Media types defined and How are they controlled?"

Pros:

1. Can define a single Media type for all .css files relatively easy
2. Could define multiple Media types - with more complex logic dependant on .css file naming
3. Could control CSS preferred and alternate style sheets - with more complex logic dependant on .css file naming
4. Compatible with Revision Control Systems (CVS, Subversion, Visual Source Safe, and so on)

In conclusion; CSS will continue to be the industry design standard - it has been the standard for well over 10 years. CSS is far more powerful than Themes and Skins, I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

Related posts:

• Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/11/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-defining-a-media-types-work-around-2/feed/ http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/ http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/#comments Fri, 10 Nov 2006 00:32:47 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,7e992478-da0f-4ce4-bb43-3a0b58f6f3ad.aspx ASP.NET 2.0's Themes and Skins have a number of design flaws - Themes and Skins depend almost entirely on Cascading Stye Sheet (CSS), but don't fully support CSS - I've listed some "Work Arounds" for a couple design flaws. I don't recommend any of these "Work Arounds" since they contribute to software entropy before your application is even developed, instead I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

The Problem / Question:
How can I exclude a subdirectory (sub folder) containing Cascading Style Sheets (CSS) in a Theme (App_Theme) directory? ASP.NET 2.0 automatically includes all CSS files (.css) from the active Theme directory and sub directories into the rendered HTML page, but doesn't allow me to exclude a folder of CSS files or a single CSS file.

The Solutions / Work Arounds:

1. Create your CSS directory outside the App_Theme directory then map a Virtual Directory inside your Theme directory.
2. Add a custom VirtualPathProvider to ignore the non-root level CSS files in sub directories  - See David Ebbo's article titled: Overriding ASP.NET combine behavior using a VirtualPathProvider.

These "Work Arounds" are useful if you want to do something like this (note: Default.css is sitting in the root of the active Theme directory):

/* Default.css */
@Import "StyleSheets/Common.css ";
@Import "StyleSheets/Masterpage.css";
<!--[if IE]>
@Import "StyleSheets/FixInternetExplorer_Quirks.css";
<![endif]-->
<!--[if IE 7]>
@Import "StyleSheets/FixInternetExplorer7Quirks.css";
<![endif]-->

Or if you wanted to use an Embedded CSS Statement like this:

<style type="text/css">
<!--
@Import "StyleSheets/HideNavigation.css";
@Import "StyleSheets/HideSearchBars.css";
-->
</style>

The Pros and Cons of this approach:

Cons:

1. Can't really define CSS media types, but we can now use the CSS @Media rule
2. Can't control CSS preferred and alternate style sheets
3. Doesn't scale well
4. Contributes to a fragile development environment
5. Not very compatible with Revision Control Systems (CVS, Subversion, Visual Source Safe, and so on)
6. Not intuitive _ a maintenance programmer's nightmare, "I know CSS, but Where is the CSS folder?" or "I know CSS, but Why and How are some CSS folders excluded?

Pros:

1. Can control the load order (inheritance and cascading) through the CSS @Import rule
2. Can exclude a folder containing CSS files
3. Can use the CSS @Import rule
4. Can use the CSS @Media rule
5. Can use Microsoft's conditional comments

In conclusion; CSS will continue to be the industry design standard - it has been the standard for well over 10 years. CSS is far more powerful than Themes and Skins, I suggest sticking with CSS and perhaps using some default Skins that define CSS classes or IDs.

Related posts:

• Where it all Falls Apart
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/09/the-problems-with-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-excluding-a-css-folder-work-around-1/feed/ http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/ http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/#comments Thu, 09 Nov 2006 01:11:28 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,4df765e2-b408-471e-9999-652cd804b683.aspx Themes and Skins are a promising addition to ASP.NET 2.0, but too immature for large web projects.

The problem with Themes and Skins begins with the way Cascading Style Sheets (CSS) are automatically included into the rendered page. Through compilation logic, ASP.NET 2.0 parses through the directory and sub directories of the active Theme. ASP.NET 2.0 automatically includes an external CSS file reference into the HTML Head tag of the rendered page for every CSS file encountered.

Here's an example for a better understanding.

My directory structure:

The output generated by Themes from the preceding directory structure:

<head> 
 <title>The Problems With Themes and Skins in ASP.NET 2.0 </title> 
 <link href="App_Themes/Default/HandHeld.css"
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/Print.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/Screen.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/FixInternetExplorer7Quirks.css"
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/FixInternetExplorerQuirks.css" 
   type="text/css" rel="stylesheet" /> 
 <link href="App_Themes/Default/StyleSheets/HideAdvertisments.css" 
   type="text/css" rel="stylesheet" />
 <link href="App_Themes/Default/StyleSheets/HideBorders.css" 
   type="text/css" rel="stylesheet" />
 <link href="App_Themes/Default/StyleSheets/HideMenus.css" 
   type="text/css" rel="stylesheet" />
</head>

As you can see, the external CSS file references are automatically included in the rendered page - the load order of CSS files seems to depend on the directory and CSS file name. In this example the root directory is parsed alphabetically then the sub directory is parsed alphabetically.

It's neat how ASP.NET 2.0 automatically includes .css files, but this behavior severely limits the use of CSS (see the list below), and encourages developers / designers to create many .css files which introduces new problems - Internet Explorer has a 30 style sheet limitation, see article Q262161.

Problems:

• As the name implies Cascading Style Sheets (CSS) depend on the order in which files are loaded (cascades), in addition to other rules like the CSS @import and CSS @Media rule. By automatically loading all .css files into the header, Themes prevent cascades and loading order from being defined.
• The automatic inclusion of .css files prevents the use of Microsoft's Conditional Comments.
• The automatic inclusion of CSS files omits the CSS Media type.

A rough list of CSS features compromised by Themes in ASP.NET 2.0:

1. CSS media types
2. The CSS @Import rule
3. The CSS @Media rule
4. Preferred and alternate style sheets
5. Media-dependent cascades
6. Inheritance and cascading
7. The use of Microsoft's Conditional Comments

An example of when these compromised features are useful:

<head>
  <title>The Problems With Themes and Skins in ASP.NET 2.0 </title>
  <link href="App_Themes/Default/HandHeld.css" 
    type="text/css" rel="stylesheet" media="handheld" />
  <link href="App_Themes/Default/Print.css" 
    type="text/css" rel="stylesheet" media="print" />
  <link href="App_Themes/Default/Screen.css" 
    type="text/css" rel="stylesheet" media="screen" />
  <!--[IF IE]>
    <link href="App_Themes/Default/StyleSheets/FixInternetExplorerQuirks.css" 
      type="text/css" rel="stylesheet" media="all" />
  <![endif]-->
  <!--[IF IE 7]>
    <link href="App_Themes/Default/StyleSheets/FixInternetExplorer7Quirks.css" 
      type="text/css" rel="stylesheet" media="all" />
  <![endif]-->
</head>

The contents of Print.css or HandHeld.css would generally look something like this:
/* Contents of Print.css or HandHeld.css*/

@Import "App_Themes/Default/StyleSheets/HideAdvertisments.css";
@Import "App_Themes/Default/StyleSheets/HideBorders.css";
@Import "App_Themes/Default/StyleSheets/HideMenus.css";

In conclusion; Themes have a number of design flaws which limit a significant portion of CSS's mature feature set. Themes are OK for small web applications, but not recommended for large / complex applications. While there are "work arounds" for some of the issues on my list, implementing each "work around" contributes to software entropy before your application is even developed. Since Skins and Themes are really based around CSS you might be better off sticking with CSS and a single default ASP.NET 2.0 Skin in which you define some default CSS classes or ID elements for some basic ASP.NET server controls.

Related notes:

Rick Strahl came to a similar conclusion:

theming is nice but really most of that can be accomplished with CSS and what Themes offers beyond that is really not that critical. [...] As it stands I don't really see how I can utilize Themes in my apps in a meaningful way. - Playing around with ASP.NET Themes

Scott Allen makes a great point:

Web designers will be more comfortable with css files. If you put the design of your site into the hands of professionals than you should be asking them to use css wherever possible. - Themes In ASP.NET 2.0

Richard P makes a related comment:

there are so many flaws in Themes and how they use CSS I dont know where to begin! [...] The concept of CSS and the web skin has been around for some years, and we have been building great solutions despite Visual Studio and ASP.NET. - Themes and Skins Flawed in ASP.NET 2.0

Learn more about Themes and Skins here: A Quick Tour of Themes in ASP.NET 2.0.

Related posts:

• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

]]> http://adam.kahtava.com/journal/2006/11/08/the-problems-with-themes-skins-and-cascading-style-sheets-css-where-it-all-falls-apart/feed/ http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/ http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/#comments Tue, 31 Oct 2006 00:26:43 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,69f6fc25-9820-4abf-a930-b119401b1dc7.aspx Themes and Skins depend on Cascading Style Sheets (CSS) and HTML / XHTML, but Themes and Skins don't fully support CSS - now that's a paradox.

HTML, XHTML, XML, and other related Markup Languages can all be manipulated through CSS - ASP.NET generates most of these languages. If your not yet familair with ASP.NET 2.0 Themes and Skins: Skins give developers and designers a little more precision to manipulate server side controls like datagrids, and calendars, but Skins fundamentally depend on CSS. Themes allow us to group our Skins, CSS files, graphics / images, and so on into logical groups or directories, but Themes really depend on CSS through Skins and CSS (.css) file references.

Both ASP.NET Themes and Skins are directly dependent on Cascading Style Sheets (CSS). However; Themes and Skins prohibit a good deal of CSS's functionality - I'll discuss this is my next post. CSS has been with us for over a decade, it's a pretty powerful display mechanism for web applications. CSS can manipulate HTML, XHTML, XML, SVG, XUL and other common Markup Languages.

I've come up with a number Theme and Skin related questions that I have yet to answer.

Questions:

If Themes and Skins rely on CSS why not just use CSS?
Answer: Default Skins are good, they provide hooks (class and ID selectors) for defining CSS. Themes are OK they let us logically group images and design related files, but fall short in a number of areas and are not recommended for large web applications. 

If it's possible to accomplish all that Skins and Themes offers through CSS why should I make the switch?
Answer: Skins can make life easier for your web designers, when used to hook into CSS classes and ID selectors.

CSS is a mature, robust language, it's been around for over 10 years so more designers / developers are familiar with it, why should I switch to a a technology that is unfamiliar to most of the people that will be maintaining the application?
Answer: It's not a clear case of CSS vs Themes since you really can't have Themes without CSS. If used properly Themes can augment CSS.

Are Themes and Skins really scalable for a large enterprise level web application?
Answer: Not really, having a seperate server or Content Delivery Network for site resources like images, stylesheets, etc... is probably the best approach. Themes and Skins do prove uesful for small web applications.

]]> http://adam.kahtava.com/journal/2006/10/30/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-2/feed/ http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/ http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/#comments Sun, 29 Oct 2006 16:06:18 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,7febbbfc-c506-45ad-817d-af62ed1645be.aspx While Themes and Skins are new to ASP.NET 2.0, the underlying concepts have been around for a long time. For those unfamiliar with Themes and Skins, skins give web designers greater flexibility to manipulating ASP.NET server side controls (calendars, datagrids, etc...) through Styles / Cascading Style Sheets (CSS). Themes logically group the design tier of an application into a common folder or directory (a Theme folder(s)), giving developers the ability to programmatically change (swap), or expose these Themes to the user.

Learn more: ASP.NET Themes and Skins Overview.
See a live example here: ASP.NET 2.0 Colorful Web Site Starter Kit.

The concept of interchanging layout and changing design styles (Themes) has been around for quite some time. The W3C Recommendation for Style Sheets in HTML documents outlines the "alternate stylesheet" that should be interchanged through the browsers menu; unfortunately Internet Explorer (IE) fails to support this method.

An example: changing style sheets with a Mozilla based browser (Firefox).

See the live example (if you're not using IE) at: www.damowmow.com.

Other methods for changing design layouts (Themes) range from Client Side Scripts (JavaScript) to Server Side Scripts (ASP, PHP, ASP.NET, and so on).

Learn more about style interchanging scripts and more here: Style Switching - css-discuss.

Themes and Skins are a welcome addition to ASP.NET 2.0, they offer a simple solution for grouping design specific files, and a nice way to programmatically change these Themes. However; this simplistic approach significantly hampers the power of Cascading Style Sheets _ I'll discuss my difficulties / problems in subsequent posts.

]]> http://adam.kahtava.com/journal/2006/10/29/a-reflection-on-themes-skins-and-cascading-style-sheets-css-in-aspnet-20-part-1/feed/ http://adam.kahtava.com/journal/2006/10/12/a-reflection-on-cascading-style-sheets-css/ http://adam.kahtava.com/journal/2006/10/12/a-reflection-on-cascading-style-sheets-css/#comments Fri, 13 Oct 2006 00:18:36 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,9343a7f1-47ff-47f3-8db7-c69740506be6.aspx I've been using Cascading Style Sheets (CSS) since the mid 90's. The lack of consistent support across browsers had always impeded my shift from table based design to CSS design. When I did make the transition, I can clearly recall the frustration, and confusion that preceded. Lately I've been using Themes and Master Pages (ASP.NET 2.0) with CSS. Personally I don't like how .NET automagically inserts the CSS file references into the header. Much of CSS's power is determined by the loading order, and the ability to define separate CSS files for Internet Explorer (IE).

I've compiled a list of techniques I find useful when developing CSS:

When designing my CSS I try to use a browser that is W3C compliant (Firefox, Opera), I then apply fixes for the many quirks found in IE.
I find it easier to develop CSS in a text editor, rather than a WYSIWIG editor - perhaps I'm a bit of a standards geek, but I like to thoroughly understand a technology rather than rely on wizards, etc...

By inserting the code below into a webpage's header you define a CSS file that will only be loaded by IE, this is great for fixing display issues in IE by overloading the effected CSS elements.
<!--[if IE]>
       <link href="IEQuirkFixFile.css" rel="stylesheet"
            type="text/css" media="all" />
<![endif]-->

You can also define different CSS files for different media types like a printer, letting us hide content (like navigation menus) that you don't want printed.
<link href="HideAllNavigationalContent.css" rel="stylesheet" type="text/css" media="print" />

You can specify other media types like: Braille, handheld, projection, tv, and so on. See more media types here: http://www.w3.org/TR/REC-CSS2/media.html#media-types

CSS can be applied in 3 different ways: Inline, Embedded, and External (Linked or Imported). It's nice to keep everything in external files as this method promotes a more n-tier approach even in the presentation level, but I also find it convenient to override classes through CSS Embedded blocks.

An example:
The following Embedded CSS will hide a Navigation menu, and increase the Content pane to 100% when inserted into webpage. Using a combination of Embedded and External CSS can allow us to use a single Master Page.

<style type="text/css">
<!--
    #Navigation
    {
        display: none;
    }
    #MainContent
    {
       max-width: 100%;
       width: 100%;
    }
-->
</ style>

CSS coupled with SVG (Scalable Vector Graphics) and Extensible Markup Language (XML) is becoming an increasingly powerful technology, and most web applications under the Web 2.0 (alternatively known as Chmod 777 web or the Read / Write Web) use CSS, XHTML, AJAX, Clean and meaningful URLs (URL Rewriting), and so on.

View a SVG example: http://www.w3schools.com/svg/svg_examples.asp

Related links:
Cascading Style Sheets Home Page
CSS Zen Garden

]]> http://adam.kahtava.com/journal/2006/10/12/a-reflection-on-cascading-style-sheets-css/feed/ http://adam.kahtava.com/journal/2006/09/17/resolving-parser-errors-unknown-server-tag-atlasscriptmanager-in-atlas-ajax/ http://adam.kahtava.com/journal/2006/09/17/resolving-parser-errors-unknown-server-tag-atlasscriptmanager-in-atlas-ajax/#comments Sun, 17 Sep 2006 14:13:44 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,b74145d5-8787-424a-b3ed-873e8fedadfc.aspx I encountered a number of Parse Error Messages while implementing the Accordion control from ATLAS.

The error messages read:
Parser Error Message: Unknown server tag 'atlas:ScriptManager'. 

Source Error:  <atlas:ScriptManager id="ScriptManager" runat="server" />

This message occured for a number of different reasons, this brief checklist should resolve your parse errors.

1) Ensure that the following assemblies are in your bin directory:
AtlasControlToolkit.dll
Microsoft.AtlasControlExtender.dll
Microsoft.Web.Atlas.dll

2) Ensure that the following has been added to your web.config file

<pages>
  <controls>
    <add namespace="Microsoft.Web.UI"
         assembly="Microsoft.Web.Atlas" tagPrefix="atlas"/>
    <add namespace="Microsoft.Web.UI.Controls"
         assembly="Microsoft.Web.Atlas" tagPrefix="atlas"/>
    <add namespace="AtlasControlToolkit"
         assembly="AtlasControlToolkit" tagPrefix="atlasToolkit"/>
  </controls>
</pages>

Related links:
Data Binding in an AccordionPane in a Repeater
Atlas Control Toolkit: Unknown Server Tag

]]> http://adam.kahtava.com/journal/2006/09/17/resolving-parser-errors-unknown-server-tag-atlasscriptmanager-in-atlas-ajax/feed/ http://adam.kahtava.com/journal/2006/07/18/a-great-source-for-ajax-frameworks-and-tutorials-wwwajaxprojectscom/ http://adam.kahtava.com/journal/2006/07/18/a-great-source-for-ajax-frameworks-and-tutorials-wwwajaxprojectscom/#comments Tue, 18 Jul 2006 23:40:06 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,fe8fbe93-2958-4054-b691-7bcfb49e3822.aspx I came across a great AJAX portal site this morning. This site covers a variety (PHP, JAVA, .NET, Ruby, etc...) of AJAX Frameworks and Tutorials. Visit Ajax Projects: http://www.ajaxprojects.com/

Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page's interactivity, speed, and usability. - Wikipedia: AJAX

]]> http://adam.kahtava.com/journal/2006/07/18/a-great-source-for-ajax-frameworks-and-tutorials-wwwajaxprojectscom/feed/ http://adam.kahtava.com/journal/2006/07/17/quality-assurance-advanced-unit-testing-nunit/ http://adam.kahtava.com/journal/2006/07/17/quality-assurance-advanced-unit-testing-nunit/#comments Tue, 18 Jul 2006 06:22:05 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,06a8aa8f-cae2-4110-801a-5201bce3de75.aspx Marc Clifton has a great five part series on Advance Unit Testing. Throughout these articles Marc builds a Unit Testing framework based on the NUnit framework - NUnit is a Unit Testing framework for Microsoft .NET, it's very similar to the JUnit framework for Java. Marc explores Unit Testing, the interworkings of Unit Testing frameworks, and the XP methodology.
Don't be intimidated by the number or size of these articles - most of the content is source code.

• Part I: Introduction to unit testing and a case study taking the XP process up to the point of writing some unit tests
• Part II: Implementation of an NUnit look-alike and developing the case study further with real tests and real code
• Part III: Implementation of NUnit extensions, revising and progressing with the case study
• Part IV: Using reflection to create unit tests that are script based instead of code based, and the impact of that on the case study
• Part V: Unit Test Patterns

]]> http://adam.kahtava.com/journal/2006/07/17/quality-assurance-advanced-unit-testing-nunit/feed/ http://adam.kahtava.com/journal/2006/07/03/the-amazon-e-commerce-service-ecs-web-services-description-language-wsdl-and-aspnet/ http://adam.kahtava.com/journal/2006/07/03/the-amazon-e-commerce-service-ecs-web-services-description-language-wsdl-and-aspnet/#comments Tue, 04 Jul 2006 00:53:14 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,9efc873e-5092-4b85-b084-3febf9261dac.aspx While developing a component for Amazon's E-Commerce Service (ECS) Web Services Description Language (WSDL) (Version 4.0), I encountered a couple minor issues and found the following links of use:

Issues:

Version 4.0 of the ECS WSDL is not compatible with Microsoft's Visual Studio (VS) 2003. However, the ECS WSDL works fine in VS 2005, a workaround for VS 2003 and other known issues can be found on the Amazon.com Associates: XML Developers Discussion Board.

Useful links:

• Philip Miseldine's tutorial titled: Use Amazon Web Services in ASP.NET
• The Amazon E-Commerce Service (ECS) Software Development Kit (SDK)
• Known Issues: Amazon.com Associates: XML Developers

This website pulls my reviews, and my recommended reading list off of Amazon.
The originating Amazon data can be viewed here: my Amazon reviews, my Amazon wish list.

]]> http://adam.kahtava.com/journal/2006/07/03/the-amazon-e-commerce-service-ecs-web-services-description-language-wsdl-and-aspnet/feed/ http://adam.kahtava.com/journal/2006/06/20/distilled-fixing-the-globalasax-in-aspnet-20/ http://adam.kahtava.com/journal/2006/06/20/distilled-fixing-the-globalasax-in-aspnet-20/#comments Wed, 21 Jun 2006 06:43:08 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,85996722-1d63-4cc8-8616-7f3daa952792.aspx Visual Studio 2005 no longer adds a code behind file to the Global.asax file.

To add a code behind file for the Global.asax file (in C#) follow these steps:

1. Open your project in Visual Studio 2005
2. Add New Item from the context menu (right clicking on your project)
3. Select the Global Application Class
4. Make sure your Global Application Class file (the .asax file) is opened
5. Delete all the contents of this .asax file
6. Add the following to this .asax file:  <%@ Application Language="C#" Inherits="Global" %>
7. Create a new class named Global in the App_Code directory
8. Copy the following source into your new Global class:

   /// Summary description for Global 
   public class Global : System.Web.HttpApplication {
    Global() { }
    void Application_Start(object sender, EventArgs e) {
     // Code that runs on application startup
    }
    void Application_End(object sender, EventArgs e) {
     // Code that runs on application shutdown
    }
    void Application_Error(object sender, EventArgs e) {
     // Code that runs when an unhandled error occurs
    }
    void Session_Start(object sender, EventArgs e) {
     // Code that runs when a new session is started
    }
    void Session_End(object sender, EventArgs e) { }
    }

9. Save, you are done

The preceding has been distilled from Ross Nelson's article: Fixing the Global.asax in ASP.NET 2.0.

On a related thread: Consider using HttpModules instead of the Global.asax file, Learn more in Karl Seguin's article titled: Global.asax? Use HttpModules Instead!

]]> http://adam.kahtava.com/journal/2006/06/20/distilled-fixing-the-globalasax-in-aspnet-20/feed/ http://adam.kahtava.com/journal/2006/05/30/the-aspnet-20-global-application-class-access-routines-and-the-globalasax-file/ http://adam.kahtava.com/journal/2006/05/30/the-aspnet-20-global-application-class-access-routines-and-the-globalasax-file/#comments Wed, 31 May 2006 06:52:27 +0000 Adam Kahtava http://adam.kahtava.com/journal/PermaLink,guid,b822b32c-c76b-4bc4-9f77-bfa73d045a74.aspx The Global Application Class has changed in ASP.NET 2.0. When adding a Global Application Class to a project, Visual Studio no longer generates a code-behind file.

The result as Ross Nelson points out is two fold: there is no class in the Global.asax, and without the class there is no "easy" way to reference Global routines / objects.

I've long been a fan of wrapping application globals into Access Routines, creating one static instance of the class, then accessing these routines through the Global class.

Ross has an excellent solution to this problem: (Fixing the Global.asax in ASP.NET 2.0).

For a summarized (distilled) version of Ross's article view: Distilled: Fixing the Global.asax in ASP.NET 2.0

]]> http://adam.kahtava.com/journal/2006/05/30/the-aspnet-20-global-application-class-access-routines-and-the-globalasax-file/feed/