We came across the following Cross Browser JavaScript problem whilst writing a bespoke show/hide function for some client FAQs.

The problem was that we were referencing the 'nextSibling' of an element in our JS using the onClick event. In IE this worked great, however in Firefox the 'nextSibling' could be a line break.

Example:

 <div id=”el1”><img src="imageName.gif" onClick="getNextSibling();" /></div>
 <div id=”el2”>Some text</div>

If the function getNextSibling equates to:  var element2 = document.getElementById(“el1”).nextSibling;
 
In the above, clicking on the image would return the nextSibling as "el2" in IE but "\n" in Firefox.

Breaking down the second line of HTML above as JavaScript would see it, it would look something like this:

"\n " (line break)
with element2.nodeName = “#text”;
element2.nodeType = 3; (that’s TEXT_NODE)
and element2.nodeValue = “\n”; (that’s a line break)

So after a bit of research we found that, if we test for 'nodeType' , and ensure that the nodeType is not equal to 1, then the nextSibling is the element we are after.

var element2 = document.getElementById(“el1”).nextSibling;
while (element2.nodeType !=1)
{
          element2 = element2.nextSibling;
}

And just to make sure...

alert(element2.nodeType);

Job done!

All tests have been created with one aim, to improve the quality of program code, to make applications and systems more reliable and stable. Recently I've been looking for short and clear explanation of what is Unit Testing.

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually. This testing mode is a component of Extreme Programming (XP), a pragmatic method of software development that takes a meticulous approach to building a product by means of continual testing and revision.

In our applications with n-tier architecture - the smallest parts could be Business Logic Layer components which obviously can be tested automatically.

Unit testing involves only those characteristics that are vital to the performance of the unit under test. This encourages developers to modify the source code without immediate concerns about how such changes might affect the functioning of other units or the program as a whole. Once all of the units in a program have been found to be working in the most efficient and error-free manner possible, larger components of the program can be evaluated by means of integration testing.

Notice that not everything should be tested under the Unit Tests first of all because of time restrictions. It may take a lot of hours to discover all possible scenarios and develop unit tests for them. Extreme Programming and Agile methodologies require quick reaction from the team members on the new changes of the developing project. However don't forget to keep testing documented as it can save a lot of time after amending some parts later.

Unit testing can be time-consuming and tedious. It demands patience and thoroughness on the part of the development team. Rigorous documentation must be maintained. Unit testing must be done with an awareness that it may not be possible to test a unit for every input scenario that will occur when the program is run in a real-world environment.

As in the real-world anything done by a human hand can contain a small mistake. So if you find something important that wasn't covered by Unit Tests just add it. As you can see, Unit Tests can't cover all components of the system, so there are other methodologies which help testers complete their work better.

Original text was taken from http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1243425,00.html

we scored another seminar for early next year with the guys from NxtGenUG

Simon and I will do another whirlwind tour of the Blend tools, wiring up the C# to make it all dynamic

Sign up and come see us in action

http://www.nxtgenug.net/ViewEvent.aspx?EventID=176

Hope to see you there, we're booked for Janurary 19th so plenty of time to get signed up

Back to the land of browser inconsistencies :¬(

I had such high hopes for the silverlight plug-in.  Cross-browser incompatablities can be the most time consuming areas of web development, so a browser plug-in overcomes these by sandboxing the application so it handles all of it's rendering internally

Or so I thought.  Having developed all my silverlight under Internet Explorer, everything renders fine with the default 100% heights and widths.  Rendering the controls is important for templated controls and the loaded event only fires when the control is rendered and the loaded event is important in order for the control to pipe up and accept some data from the dartabinding process. 

To my amazement, and slight relief, Firefox actually requires a fixed height in order for it to render.  By default, you are given a silverlight plugin, set to 100% height and width, wrapped in a div with a height : 100% style attribute.  Just change the containing div to a fixed height and your controls now render fine in Firefox :¬)

so from this

<div style="height: 100%;">

<asp:Silverlight ID="Xaml1" runat="server" Source="~/ClientBin/NavTeqBannerMain.xap" MinimumVersion="2.0.31005.0" Width="100%" Height="100%" InitParameters="ctlid=SilverLightBanner" />

</div>

to this

<div style="height: 256px;">

<asp:Silverlight ID="Xaml1" runat="server" Source="~/ClientBin/NavTeqBannerMain.xap" MinimumVersion="2.0.31005.0" Width="100%" Height="100%" InitParameters="ctlid=SilverLightBanner" />

</div>

 

It's fair to says IIS7 has some differences when compared to IIS6 (Well, Duh!)

The one I found most difficult to get my head around was the Wildcard Handler Mappings.  Traditionally, we wrote the handler in .net, or used the global.asax file to map the requested re-written URL to a pgae in the application.  IIS6 had the option to specify whether or not the file exists.

For example, you request http://www.creative-jar.com/News.  There is not physical file called News in the root, and even if there was, there's no extension on the file in the URL so IIS wouldn't know which dll to map it to, generating a 404 beacuse the file isn't found.  So, you set the WildCard handler to NOT verify that the file exists, before passing it to the handler to do it's magic

It's this Verify File Exists option that's missing in IIS7, causing the 404 to fire before your handler even get's a bite of the apple.

I found a good post on the subject here.  It explains the extra steps you need to get IIS7 not verifying files in your web application, instead just passing the whole request to your app and let it carry on as normal.  The post links through to an open-source UrlRewriting HttpHander called UrlRewriter.NET which has such a simple setup, it's untrue.  It currently uses a section of the web-config to work out it's mappings but, being that it's open-source, you can change it to collect from wherever you like

enjoy :¬)

Man, I love the .net framework.  Each release see me writing less and less of the boring stuff, allowing me to concentrate on the more exciting things in development.  However, as each release passes by, I'm always left with the thought : "How did we cope before this release??!?!!"

It struck home good and proper today.

A Web Agency strives for perfection in design, perfection in usablity, perfection in accessability, perfection.*.  W3C validation is one of the many tests we put our sites under, and it gives some really good feedback on your mark-up ; which attribute have you forgetten to add? Which elements fit inside which elements?

We  know, by now, that <span> can contain very few HTML elements.  This has been the case for all eternity.  So, why oh why, does setting RepeatLayout.Flow on a DataList make anyone @ Microsoft think it's going to get away with wrapping each template up in a <span> when it can contain so few elements?

Thats the problem i was having today.  Alexey had coded me up some excellent HeaderTemplate, FooterTemplate and ItemTemplate for one of our ZoomSpace applications.  The raw HTML looked brilliant, the HTML was W3C compliant, everyone was happy, especially me.

Along comes DataList to ruin my day by injecting it's dodgy, non-compliant, and downright short-sighted markup into my ResponseStream.

DataList was prevalent in .net 2.0.  A good, lightweight, databound control which you could use to edit items, delete stuff, add new items, the lot.  I know the purer way would be to use the Repeater, but i needed the data-driven code.  I could have used ListView, but this a .net 2.0 application so that's out too.

We've been using ListView for a while.  It's pure mark-up, no additions and no weirdness.  How  easy I forget how different things were!!

I had to do this recently and thought it would be tougher than it ended up being. Here's the code I used:

function adjustMyFrameHeight()
{
var frame = getElement("myFrame");
frame.height = document.body.offsetHeight + 60 + "px"; // add 60 pixels to be safe...
}

function getElement(aID)
{
return (document.getElementById) ?
     parent.document.getElementById(aID) : parent.document.all[aID];
}

Then, just simply call the "adjustMyFrameHeight()" method from the child page's BODY onload event:

<body onload="adjustMyFrameHeight();">

Et voila, c'est bon!!

A couple of the CJ Dev team were down in Brighton for Re-Mix 2008 a few weeks ago, and one of the most useful sessions I went to was "ASP.NET Front End Performance" by Chris Hay.

There's some really obvious things, but others that I didn't know. I've collated the key points together for easy reference:

• Combine all JavaScript files together (i.e. single request)
• Combine all CSS files together (i.e. single request)
• Use inline scripts and CSS on the home page, load script and CSS assets post UI
• Reduce image requests
  • Use image maps
  • Use large background images
• Implement IIS caching
• Use versioning policy on filenames to avoid unwanted caching (e.g. my-js-file-001.js)
• Use Server.Transfer instead of Response.Redirect where possible
• Use SilverLight controls for common areas of the site (headers, footers, etc.)
• Implement HTTP compression in IIS
• Use the .NET ViewState wisely
  • Only on pages where necessary
  • Compress the ViewState
  • Offload ViewState to Session if possible / advantageous
• Avoid use of .NET UpdatePanel control where possible
• Expose web services to AJAX for use by JavaScript code, manually altering DOM
• Combine auto generated scripts by .NET framework (e.g. ScriptResource.axd)
  • Use script resource profiler to discover all script files
• Use SilverLight instead of AJAX
  • Detect presence of SilverLight, and fail safe to AJAX if preferred to forcing use of SilverLight
• Use Content Delivery Network where applicable (large projects) to bring the content closer to the user
• Implement use of data caching
• Use page / control output caching  
• Queue requests for processing (if any large / long requests will occur)
• Ensure all debug flags are removed from application

Cheers to Chris Hay!!

For those trying to make headway into Silverlight, there is a lot of old knowledge which needs to be gained in order for silverlight to become productive. 

For Flash-heads, there simply isn't enough material about to make a judgement about which one to use.  Based on in-house experience, and the fact that people won't have previous Silverlight experience (it was only released on the 14th October), Flash is tried and tested

Then along comes Project Rosetta with a 10 lesson how-to on comparing some old Flash-staples to new Silverlight techniques, code for both versions and working demos to boot!!

The new silverlight tools can now be accessed using the FREE Visual Web Developer edition of Visual Studio 2008, and there's trial version of Blend if you want to your Draw on :¬)

Enjoy

Tim

 

We all remember good old “clearfix” (www.webtoolkit.info/css-clearfix.html) that we use to clear floats.

This is a new “lighter” version, based on the same principle.

.clearfix:after { content: ""; display: block; clear: both;}.clearfix { //display: inline-block;}

The major difference from the original clearfix is that we use blank content (“”) in “:after”, instead of “.” in the original one. That helps us to get rid of three extra lines of code, which purpose was to hide this dot:

visibility: hidden; line-height: 0; height: 0;

and to get rid of one more IE6 specific selector used for the same reason.

* html .clearfix { height: 1%;}

If you not too concerned about validity of your CSS you could leave the code as it is, else you can put .clearfix {//display:inline-block;} (the IE specific declaration) into separate IE Only CSS, or use the same trick, as per original clearfix – redefine “inline-block” to simply “block” for not IE, using:

html[xmlns] .clearfix { display: block;}

after IE’s “inline-block”.