Altitude Blog

The traditional method of debugging Javascript in the browser involves using the alert method to display a dialog box. Clicking OK for the 100th or attempting to debug browser events will soon have you ready for a new approach.

Firebug has a handy console pane which displays erros and allows you to enter Javascript and execute it immediately.

Using Firebug's console API you can also log messages to the console from within your browser scripts and avoid the pain of repeated alert dialog boxes.

The log method takes an argument and prints it in the console.

 

console.log('Total price is');
console.log(totalPrice);

 

Several arguments can be passed and Firebug will join them together, separated by a space:

 

console.log('Total price is $', totalPrice, ' and the time was ', transactionTime);

 

console.log() will take an object, too, but a better choice can be console.debug();

 

console.debug(window.location);

 

The debug method automatically creates a link in the console window. Clicking the link in your Firebug console takes you to the DOM inspector for that object.

For small objects it can be useful to show their contents right here in the console window.

 

console.dir(window.location);

 

There are several more console methods available. Read through the Firebug Console API documenation to find out more.

Visual Studio allows the creation of a new project type call Web Application Project. This is different from the standard ASP.NET web site project. The WAP is based more on the application model of setup. Class and component files can be added anywhere within the project and they will be compiled normally.

For more information on converting your 2005 web site to a WAP site visit http://msdn2.microsoft.com/en-us/library/aa983456.aspx.

I recently upgraded a Linq beta product from the Beta to Final Release.

Lucky there were very few errors except for the default methods of add and delete on the System.Data.Linq.Table. The replacement methods are now InsertOnSubmit or DeleteOnSubmit. It is interesting to think that the conversation's that took place to make such a fundamental change to one of the methods. Obviously it the new methods are more descriptive but the amount of coding hours it has cost beta developers makes you wonder. I now always think twice about naming public methods. 

• Keep it simple. Forget all you know about tableless design and advanced CSS as HTML support in Email is awful. The worst offenders are the latest Outlook clients. So write your html as though you are still in the 90's.
• Use inline CSS. The web based email clients strip out all the information from the body tag up. So using inline CSS the best way to go. Remember though not all CSS is recognised in some Email clients due to security issues so try stick to HTML for formatting that includes using tables for layout design.
• Images do not always display by default in the majority of clients and most of the time the alt tags are not displayed. So make sure all your content is text based. Another area to watch out for is the layout of the email. Without inserting the width and height settings the blank placeholders for your images will throw out your layout.
• HTML Email sizing. Best practice would dictate that emails use percentages for sizing as you have no idea on the dimensions of the email client. However if the design is fixed layout then try between 500px and 600px.
• Avoid JavaScript. The vast majority of clients will remove it.
• Spacing is very tricky as css margin and padding does not always work stick to td with width and height settings.
• Links should use the target=_blank. Online email clients do not want to lose their session when clicking a new link.
• Background images. Don't bother trying to setup background images as most clients will not display them. Rather slice your images and around the content.

I received this message while creating my first ASP.NET AJAX web service.

The call to the asyncronise method has changed from (userparameters, onComplete, onTimeOut, onError) to (userparameters, onSuccess, onFail, userContext).

Obviously this is an improvement as you can now track userContext of the Webservice calls.

To fix the above message make sure you are defining your userContext even if it is null. For example:

 <script language="javascript" type="text/javascript">

 var userContext1;       

 WebContentFlow.AJAX.ContentflowAJAXAPI.BuildPage("String parameter",onSuccess,onFailed,userContext1)      

 function onSuccess(result,userContext,sender)        {            alert(result);        }        

 function onFailed(result)        {            alert("Failed request >"  + result.get_message());       

}