Over the next few days I’ll be converting my CRM codebase to the new beta.

I’ll keep everyone posted on what has changed.

I’ll give a mini-review after i’ve had time to play with it over the Thanksgiving holiday.

Here is how you do it in MSSQL.

DECLARE @totals INT
EXEC sp_executesql N’SELECT @totalCount = count(*) from sysobjects’, N’@totalCount INT OUTPUT’, @totals OUTPUT
print ‘Totals: ‘ + convert(varchar,@totals)

I’m really looking forward to the integrated AJAX tools and the built in MVC framework.

http://www.vnunet.com/vnunet/news/2202822/microsoft-sets-date-fro-visual

 1. Maintain the position of the scrollbar on postbacks:  In ASP.NET 1.1 it was a pain to maintain the position of the scrollbar when doing a postback operation.  This was especially true when you had a grid on the page and went to edit a specific row.  Instead of staying on the desired row, the page would reload and you’d be placed back at the top and have to scroll down.  In ASP.NET 2.0 you can simply add the MaintainScrollPostionOnPostBack attribute to the Page directive:

<%@ Page Language=”C#” MaintainScrollPositionOnPostback=”true” AutoEventWireup=”true” CodeFile=”…” Inherits=”…” %>

2.  Set the default focus to a control when the page loads:  This is another extremely simple thing that can be done without resorting to writing JavaScript.  If you only have a single textbox (or two) on a page why should the user have to click in the textbox to start typing?  Shouldn’t the cursor already be blinking in the textbox so they can type away?  Using the DefaultFocus property of the HtmlForm control you can easily do this.

<form id=”frm” DefaultFocus=”txtUserName” runat=”server”>
  …
</form>

3. Set the default button that is triggered when the user hits the enter key:  This was a major pain point in ASP.NET 1.1 and required some JavaScript to be written to ensure that when the user hit the enter key that the appropriate button on the form triggered a “click” event on the server-side.  Fortunately, you can now use the HtmlForm control’s DefaultButton property to set which button should be clicked when the user hits enter.  This property is also available on the Panel control in cases where different buttons should be triggered as a user moves into different Panels on a page.

<form id=”frm” DefaultButton=”btnSubmit” runat=”server”>
  …
</form>

4. Locate nested controls easily: Finding controls within a Page’s control hierarchy can be painful but if you know how the controls are nested you can use the lesser known “$” shortcut to find controls without having to write recursive code.  If you’re looking for a great way to recursively find a control (in cases where you don’t know the exact control nesting) check out my good buddy Michael Palermo’s blog entry. The following example shows how to use the DefaultFocus property to set the focus on a textbox that is nested inside of a FormView control.  Notice that the “$” is used to delimit the nesting:

<form id=”form1″ runat=”server” DefaultFocus=”formVw$txtName”>
<div>
<asp:FormView ID=”formVw” runat=”server”>
<ItemTemplate>
Name: 
<asp:TextBox ID=”txtName” runat=”server” 
Text=’<%# Eval(“FirstName”) + ” ” + Eval(“LastName”) %>’ />
</ItemTemplate>
</asp:FormView>
</div>
</form>

This little trick can also be used on the server-side when calling FindControl().  I blogged about this awhile back if you’d like more details.  Here’s an example:

TextBox tb = this.FindControl(“form1$formVw$txtName”) as TextBox;
if (tb != null)
{
//Access TextBox control
}

5. Strongly-typed access to cross-page postback controls:  This one is a little more involved than the others, but quite useful.  ASP.NET 2.0 introduced the concept of cross-page postbacks where one page could postback information to a page other than itself.  This is done by setting the PostBackUrl property of a button to the name of the page that the button should postback data to.  Normally, the posted data can be accessed by doing something like PreviousPage.FindControl(“ControlID”).  However, this requires a cast if you need to access properties of the target control in the previous page (which you normally need to do).  If you add a public property into the code-behind page that initiates the postback operation, you can access the property in a strongly-typed manner by adding the PreviousPageType directive into the target page of the postback.  That may sound a little confusing if you haven’t done it so let me explain a little more.

If you have a page called Default.aspx that exposes a public property that returns a Textbox that is defined in the page, the page that data is posted to (lets call it SearchResults.aspx) can access that property in a strongly-typed manner (no FindControl() call is necessary) by adding the PreviousPageType directive into the top of the page:

<%@ PreviousPageType VirtualPath=”Default.aspx” %>

By adding this directive, the code in SearchResults.aspx can access the TextBox defined in Default.aspx in a strongly-typed manner.  The following example assumes the property defined in Default.aspx is named SearchTextBox.

TextBox tb = PreviousPage.SearchTextBox;

This code obviously only works if the previous page is Default.aspx.  PreviousPageType also has a TypeName property as well where you could define a base type that one or more pages derive from to make this technique work with multiple pages.  You can learn more about PreviousPageType here.

6. Strongly-typed access to Master Pages controls: The PreviousPageType directive isn’t the only one that provides strongly-typed access to controls.  If you have public properties defined in a Master Page that you’d like to access in a strongly-typed manner you can add the MasterType directive into a page as shown next (note that the MasterType directive also allows a TypeName to be defined as with the PreviousPageType directive):

<%@ MasterType VirtualPath=”MasterPage.master” %>

You can then access properties in the target master page from a content page by writing code like the following:

this.Master.HeaderText = ”Label updated using MasterType directive with VirtualPath attribute.”;

You can find several other tips and tricks related to working with master pages including sharing master pages across IIS virtual directories at a previous blog post I wrote. 

7. Validation groups: You may have a page that has multiple controls and multiple buttons.  When one of the buttons is clicked you want specific validator controls to be evaluated rather than all of the validators defined on the page.  With ASP.NET 1.1 there wasn’t a great way to handle this without resorting to some hack code.  ASP.NET 2.0 adds a ValidationGroup property to all validator controls and buttons (Button, LinkButton, etc.) that easily solves the problem.  If you have a TextBox at the top of a page that has a RequiredFieldValidator next to it and a Button control, you can fire that one validator when the button is clicked by setting the ValidationGroup property on the button and on the RequiredFieldValidator to the same value.  Any other validators not in the defined ValidationGroup will be ignored when the button is clicked. Here’s an example:

<form id=”form1″ runat=”server”>
    Search Text: <asp:TextBox ID=”txtSearch” runat=”server” /> 
    <asp:RequiredFieldValidator ID=”valSearch” runat=”Server”
      ControlToValidate=”txtSearch” ValidationGroup=”SearchGroup” /> 
    <asp:Button ID=”btnSearch” runat=”server” Text=”Search”
ValidationGroup=”SearchGroup” />
    ….
    Other controls with validators and buttons defined here
</form>

8. Finding control/variable names while typing code:  This tip is a bit more related to VS.NET than to ASP.NET directly, but it’s definitely helpful for those of you who remember the first few characters of control variable name (or any variable for that matter) but can’t remember the complete name.  It also gives me the chance to mention two great downloads from Microsoft.  First the tip though.  After typing the first few characters of a control/variable name, hit CTRL + SPACEBAR and VS.NET will bring up a short list of matching items.  Definitely a lot easier than searching for the control/variable definition.  Thanks to Darryl for the tip.  For those who are interested, Microsoft made all of the VS.NET keyboard shortcuts available in a nice downloadable and printable guide.  Get the C# version here and the VB.NET version here.

As most of you know, ASP.NET AJAX v1.0 was officially released last week.  The release was accompanied by loads of videos and sample code that should get any .NET Developer off the ground and running with AJAX in no time at all. 

Most of the thanks goes to the wonderful developers responsible for developing ASP.NET AJax, but certainly Microsoft has done a lot to make these tools happen.

Here are some links to get you started:

- Main ASP.NET AJAX site: http://ajax.asp.net

- ASP.NET AJAX Download.  With ASP.NET AJAX, developers can quickly create pages with rich, responsive UI and more efficient client-server communication by simply adding a few server controls to their pages. This new Web development technology from Microsoft integrates cross-browser client script libraries with the ASP.NET 2.0 development framework. ASP.NET AJAX provides developers building client-based Web experiences with a familiar development process and programming model that they already know from using server-side ASP.NET development. Because ASP.NET AJAX is integrated with ASP.NET, developers have full access to the built-in ASP.NET 2.0 application services and the entire .NET Framework. 

- ASP.NET AJAX Control Toolkit.  The ASP.NET AJAX Control Toolkit offers developers a rich variety of client-side controls and extenders through a compilation of code samples and components. If you’re looking for eye-catching control behavior without having to go through the trouble of writing and testing extensive JavaScript code or adding complex animations, the ASP.NET AJAX Control Toolkit offers the right balance of visuals and ease-of-use.

- ASP.NET AJAX Library.  The Microsoft AJAX Library is a standalone collection of the standards-based JavaScript classes included in ASP.NET AJAX. It’s supported by most popular browsers and can be used to build client-centric Web applications that integrate with any backend data provider.

I suggest everyone take a look at these wonderful .NET tools.  AJAX is not going away anytime soon, and it is important to realize the benefits that this “old but re-juvinated” techology is bringing to the web.

Well the hype of Web2.0 has certainly revitalized Javascript in the web development community.  Just when you think it’s dead…  I look forward to researching each of these libraries more thoroughly and then incorporate the best suited one into Kinetic CRM.

Here is the summary of the 4 main libraries as described by Sitepoint.

Dojo:

The great thing about Dojo is that it’s so rich in features. The Widget system provides a raft of useful controls such as a DatePicker, a RichText widget, as well as a considerable number of controls that you would expect to find in something like Microsoft’s MFC. In addition to this, you can build your own widgets on the framework using HTML, CSS and JavaScript (see this article for details).

But JavaScript need not be limited just to the browser, and Dojo is designed with this in mind. Dojo’s platform independence could make it an interesting platform for desktop widget development, as well as many other potential applications. As an example, Open Laszlo recently announced that it was licensing Dojo for its JavaScript implementation of the platform.

Dojo’s design has quite a Java-like aesthetic without trying to be Java. In fact, I’d say Dojo utilises JavaScript as a language exceptionally well. One downside of the library’s design, though, is the sometimes long package strings that you need to type out to call the methods or instantiate the library’s objects — it would be nice if Dojo could provide a way to “mix” a package into the global or local scope. This would provide ready access to a certain package if you planned on using a lot of methods from it, although I’m not sure how easily it could be incorporated.

Additionally, for all its features, Dojo is completely missing any functions that could aid the selection of DOM elements — something that’s quite fundamental to DOM Scripting. It seems to be quite a gaping hole in the library — it would be great to be able to select elements using CSS and/or XPath. Similarly, while some of the objects in the library seem to support a kind of iteration framework, Dojo is lacking in methods for iterating though arrays and collections, a task which seems to make up the bulk of DOM scripting tasks.
And at this point in time, documentation for Dojo is not at a premium. The official Dojo site contains some API documentation that’s far from complete, but it does have some well-written articles highlighting areas of the library. The JavaScript community has yet to embrace the daunting task of documenting Dojo, though, so independent on the topic articles are few and far between.

Mochikit:

First off, Mochikit’s logging framework is excellent. Simply add logging statements:

log("This is so much better than alert");
log("ERROR This thing is broke");

You can then use Mochikit’s bookmarklet to open a log window and view your log messages. You don’t need to add anything into your pages or include any extra script — it’s truly effortless and beats alert any day.

Mochikit also makes full use of JavaScript’s functional programming features to really enhance and simplify the library’s API. For instance, if you want to sort a group of objects by their name properties, you can use keyComparator to create the sort function for you:

var sortedByName = people.sort(keyComparator("name"));

There’s also the useful counter function. This creates a function which returns a value that’s incremented by one every time it’s called:

var nextId = counter();
nextId(); //=> 1 
nextId(); //=> 2 
nextId(); //=> 3

There’s also a full set of Python-style iteration functions, such as forEach, map and filter, which are sure to see heavy use.

As far as documentation goes, Mochikit has some very good API documentation, but details on some very basic parts of the library are a little lacking. In particular, after reading all the docs, watching the screencast and writing a few Mochikit-based scripts, I’m still unsure which version of the library is best suited for any purpose. Do I use the packed version or the main Mochikit.js? How can I load individual parts of the library?
However, Mochikit does have a mailing list, so answers to these kinds of questions are, no doubt, not far away. All in all, Mochikit may not be what you’re used to in terms of a JavaScript library, but it’s beautifully designed and I’m looking forward to seeing where Bob takes it.

Prototype/Script.aculo.us:

Convenience is king with Prototype. Most notably, the $ function (which selects elements by id) and the $$ function (which selects elements using CSS selectors) provide extremely quick access to elements on the page. The $$ function even supports CSS3 selectors — most browsers don’t. When you use it in conjunction with the enumerable methods and Prototype’s other convenience methods, you can come up with some pretty concise statements. For instance, to hide all div elements with a class of /#c#”obscene”:

$$("div.obscene").map(Element.hide);
$$("a[href='http://']").each(function(element)
 {
   Event.observe(element, 'click', openNewWindow);
 }
);

As we all spend most of our scripting time working through lists of DOM nodes, this buys us a lot of power indeed. The compact and intuitive API really is the killer feature of Prototype for me.

Scriptaculous is a great, extensive effects library with solid drag-and-drop support that, again, is ridiculously easy to use. Consider this:

new Draggable('my_element');

This produces an element that the user can drag. You can then add further configuration using object notation, like this:

new Draggable('my_element',
 {
   revert : true
 }
);

Documentation was very limited for a long time, but recently many people have filled the gap, making Prototype one of the most widely documented of the big JavaScript libraries, albeit that that documentation is a bit splintered. There are no central API docs, but there’s a whole raft of libraries that cover parts of the library, as well as Jonathan Snook’s excellent cheat sheet detailing the entire library. The prototypedoc.com site also maintains a pretty thorough list of articles about Prototype to help you get started with the library.

Yahoo UI Library:

The documentation provided by Yahoo! for the library is excellent. The site has formal API documentation, plenty of examples, a mailing list and some brief but clear explanations of the main features of each part of the library. However, as with Dojo and Mochikit, the library has not quite managed to capture the imagination of the developer community as much as Prototype, so independent articles are still thin on the ground at the moment. The best place to check for articles about YUI is Yahoo! developer, Dustin Diaz’s site .

As I implied above, the event handling implementation is one of YUI’s main strengths, and the fact that it is decoupled from the other parts of the library means that it could well see a lot of use independently from the rest of the library. However, the rest of the library, while being very functional, doesn’t contain as many innovative features as the likes of Mochikit, Dojo and Prototype, and because of the long package strings, coding with YUI sometimes feel rather long-winded.

Yet the growing list of components is very rich. For instance, the Calendar component supports several languages and multiple date selections, and the Container classes give you the power to implement all kinds of windowed interfaces. One downside of using these components is that they tend to be very heavily dependent on the other libraries; in discussing this, Dean Edwards highlights as an example the treeview control, which uses around 260K of JavaScript.

So Who Wins?

Well, the short answer to this question is that there is no real stand-out solution that excels in all situations.

Prototype is the most comprehensively documented — albeit in a splintered way. It is also seemingly the most widespread library at the moment, possibly because it really excels at the kind of tasks developers complete most often, like selecting nodes and working with lists. Of course, it’s going to be the natural choice for Ruby developers because it sticks to many Ruby idioms. One other great thing about Prototype is that it has the mighty weight of Rails behind it and, as a result, there are many developers providing bug fixes and patches to Prototype. Finally, it offers a wealth of add-on libraries such as scriptaculous, Rico, and Behaviour that make it a good, solid choice for many developers.

On the other hand, Prototype has a very under-developed event handling framework, which is a major problem for an otherwise powerful library. Also — and this is purely a matter of taste — Prototype’s super-pragmatic approach to things (like the heavy use of the innerHTML property) can seem a little “dirty” sometimes.

For smaller projects, the decoupled design and fully-featured components of YUI may well be a big plus. It’s very easy to drop in the Connection Manager or the Event library and get going on some basic tasks without having to traverse too much of a learning curve. On the whole, though, it doesn’t have much to offer in terms of cool or powerful features.

Dojo is definitely the daddy of the bunch — you can almost always rely on it for the most powerful implementation of any feature. And Dojo’s focus on performance is an absolute godsend if you’re planning a very JavaScript-intensive application. The widget implementation also has enormous potential for building complex UIs. However it really is quite big — both in terms of its file size and the size of the API — so I wouldn’t recommend it for smaller projects.

In my opinion, Mochikit is by far the most well designed and well thought out of the four, and Python/Twisted/Nevow developers will definitely find its API very familiar. However, its documentation is a bit thin in some places (for instance, I’m still a little unsure as to which version of the Mochikit distribution to put in the script tag). Also, some of the idioms and functional techniques that it uses may be confusing for beginners or those who aren’t well versed in functional programming techniques. However, it really is worth a look. Mochikits’s capabilities will probably surprise you — the createDOM function, iteration tools and the asynchronous architecture are a work of art.