The javascript-only package includes 3 javascript files that allow you to use the default Microsoft AjaxHelper. You can just copy those files to your Content folder and include them in your head section, instead of the MicrosoftAjax.js and MicrosoftMvcAjax.js. All ajax extensions work the same as their Microsoft equivalence,  using jQuery instead of MicrosoftAjax. As a little bonus, you’ll get back and forward button support for your ajax-links.

That’s it, go ahead and use the AjaxHelper functions like you’re used to. Though a few things have changed for the AjaxHelpers in preview 5, you could still use the introduction ASP.NET MVC Preview 4 – Using Ajax and Ajax.Form by Scott Hanselman if you haven’t already checked out the AjaxHelper. Main thing that has changed is that you cannot use inline javascript in the AjaxOptions in preview 5, you should now specify a method name. You could also download the entire jQueryMvc project, it holds a sample website showing some of the ajax magic.

Talking about the entire project, it’s more than just the .js files! The intention of the project is to get you up and running very quickly when you want to create an mvc based ajax application. We use Unity as our default IoC container.

I think it’s quite hard to explain exactly what the project does for you, it’s best really to just look at the sample website, but I will give a brief overview. First, we have a DefaultViewViewEngine. If you mark your controller with a [DefaultView] attribute like so:

If you call in example /Home/Index, by default the Index view will be searched for. If it isn’t found, the DefaultViewViewEngine will look for a template with the name specified ("default" in the above example). It doesn’t matter what viewengine you use for your views, it will work for all of them. So what can this do? Look at the structure of the views in the sample site:

As you can see, most of the the views only have an ascx file prefixed with an underscore. Since the views are not found when the actions Home/About, Home/SayHello, Home/Index are called upon, the DefaultViewViewEngine will open Shared/Default.aspx.
This default page does not do much

As you can see, it just uses the masterpage. But with only little imagination, you can see that you can easily create different default-pages for each controller. The masterpage however, does hold some extra magic:

This special contentplaceholder, by default works like a normal placeholder. But, if it doesn’t get new content from it’s page, it will ask the ViewEngine(s) to open the view of the current action prefixed with an underscore. So, if you call Home/About, this will ask for Home/_About. 
Can you see the magic? For all similar pages, you just have to create the ascx files (or other partials if you use a different viewengine). Those partial views will be pushed into the main page.

But wait, there’s more! If you make an ajax-request to a controller that has the [AjaxController] attribute, it will return only the partial view! Now, isn’t that great ? That looks a lot like the updatepanel to me

Go to codeplex and download the project to see the ajax-magic I’m so excited about!
Source can be downloaded at Google code: http://code.google.com/p/jquerymvc/source/checkout
The sample website can be seen in action at: http://www.chrisvandesteeg.nl/demo/jquerymvc5/

Unfortunately the AjaxHelper itself is sealed, so atm we can’t (easily) change how the AjaxHelper generates its links. So, as an alternative, I created a javascript library that uses the same methodnames as the MicrosoftMvcAjax version.

Though at first I was upset that AjaxHelper wasn’t opened up, this javascript-only solution makes it very easy to use. All you have to do is

• place the latest jQuery version in your Content folder;
• place my javascript file in your Content folder;
• add references in your views (or masterpage ofcourse) to these 2 files instead of referencing the MicrosoftMvcAjax.js and MicrosoftAjax.js file.

If you haven’t played with the AjaxHelper yet, take a look at Scott Hanselman’s post on Using Ajax and Ajax.Form

This jQuery version also has a little extra: browser-history support for your ajax requests

Now, go download the js file and play!

So, quite some things have changed in preview 3, which made me decide to change a lot in the jQuery for Asp.net mvc (jqmvc) too. To start with most radical one: I ditched the ajax.master. This little ‘framework’ does not rely on a special masterpage in your website from now on. Since things have radically changed, I’ll start all over again on how to use this project.

In this post, I’ll explain how the project works globally. I won’t go into too much details about everything, but I will just explain the things you’ll directly touch in your application. In the next post, I’ll explain how to use the project in your website (until that time you could take a look at the included sample website). That post will explain the Ajax- and HtmlHelpers in this project and it will explain how to do an ajax request using jQuery.

Before my story starts, let’s start with the links and downloads for all those who want to read code rather than stories :

• Downloads 
• SVN source Repository
• The online demo
• Codeplex homepage

Application and routes

To have a quick go for your application, it’s recommended that you inherit your application from JqueryMvc.JqueryMvcApplication. You can ofcourse easily do this in your global.asax like so:

This application sets up the Unity dependency container and will set up the default routes. If you wish to setup a different (or no) dependency container, you should override InitializeContainer() and ConfigureContainer(). JQueryMvc itself is no longer dependent on a dependency container.

I found it hard to set up the default routes in preview 3 if your server does not support wildcard redirects (like visual studio’s webdevserver doesn’t). In that case you need to catch existing files (default.aspx needs to exist, but shouldn’t do anything), but you need to skip the Content folder. I came up with the following solution:

So if there’s a default.aspx in the root of your application, it set’s routeExistingFiles to true. If the url matches the RegEx ^Content\/.* the routing will be stopped using the new IgnoreRoute method. Also, your controllers will then be extended with .aspx to be sure the requests passes the asp.net cycle. If you have the option to catch all incoming requests, all you have to do is remove the default.aspx from the root of your website.

Controllers

As you’ve seen in Scott’s post, controllers should now return an ActionResult. The normal way would be to have your controller action return the result of the View() method. With jqmvc you should not call the View() method at the end of your action. Ofcourse, if you’re sure you want to return the normal view, you could still do so. In jqmvc there is a ExtController which you should inherit your controllers from. This baseclass contains a method called Action() which accepts the same attributes as View() but does some magic to decide what type of request the current request is, and will try to return the correct ActionResult for that type of request. This could be either an Ajax-request, a Json request or a normal page-request. Your typical controller with some actions would look like this:

Views

If jqmvc encountered the current request as a normal page request, it will create the default ViewResult, nothing special there.

If jqmvc decided Json should be returned, a JsonResult is created and no further actions will be taken. The rendered view will be the ViewData serialized to Json. The ViewEngine of the controller is also changed to a JsonViewEngine but this is only called upon in case of an Exception.

If jqmvc decided that the request is an Ajax request, it will create a normal ViewResult, but it will change the ViewLocator of the controller.
(Offtopic: I think it’s a design-error to have the viewlocator on the controller. It should be on the ViewResult object, that’s the only object that uses it. Perhaps this will be changed in the next preview…)
This AjaxViewLocator will first look for .ascx files instead of .aspx files. If it can’t find the .ascx it will load .aspx afterall.  You can also create a target-specific .ascx file: if you do an ajax-request through our javascript function jQuery.mvc.request() (or one of the htmlhelper functions), you have to specify a target for the loaded content. Let’s say we want to load /Home/Index into a <div id="dynamiccontent"></div>
The AjaxViewLocator will then look for :

1. /Views/Home/Index.dynamiccontent.ascx
2. /Views/Home/Index.acx
3. /Views/Home/dynamiccontent.ascx
4. /Views/Home/Index.aspx
5. /Views/Shared/Index.dynamiccontent.ascx
6. /Views/Shared/Index.ascx
7. /Views/Shared/dynamiccontent.ascx
8. /Views/Shared/Index.aspx

To have the page /Home/index available both as an ajax request as well as normal request, you could create an /Views/Home/Index.aspx which loads the index.ascx like so:

Things to know

• We have some HelperClasses to simplify the use of jqmvc

• The ViewData keys "Messages" and "Errors" are treated specially by jqmvc.

• Your page should always contain:

  • <%= Html.RegisterJqueryMvc(Page.ClientScript) %> To register the required javascript files

  • <div id="loading"></div>; or something else with id="loading". This will be made visible during ajax-requests

  • <div id="errors"></div> to display errors

  • <div id="messages"></div> to display messages (informational)

• We have a special contentplaceholder in JqueryMvc.UI.WebControls.ContentPlaceHolder. This will use the AjaxViewLocator to load some default content. Eg, if used like this in your masterpage, and the current request is /Home/Index:
  <jq:ContentPlaceHolder ID="maincontent" runat="server" />
  It will look for for content in:

  1. /Views/Home/Index.maincontent.ascx
  2. /Views/Home/Index.acx
  3. /Views/Home/maincontent.ascx
  4. /Views/Home/Index.aspx
  5. /Views/Shared/Index.maincontent.ascx
  6. /Views/Shared/Index.ascx
  7. /Views/Shared/maincontent.ascx
  8. /Views/Shared/Index.aspx

     This way, your index.aspx could just be an empty page that points to MasterPage with this default-content-loading contentplaceholer.

• Your ascx files should inherit from JqueryMvc.Mvc.ExtViewUserControl to have access to the AjaxHelper (bug in asp.net mvc!) and to have the messages & errors parsed by jqmvc.
• In case of an error the default controller will look for a rescue page in /Views/[ControllerName]/Rescues/error.aspx or /Views/Shared/Rescues/error.aspx (or .ascx in case of an ajax request). You can specify your own rescues for different types of errors by using the RescueAttribute of
• You should remove default.aspx if your application-server supports wildcard mappings.

I also made up a nice(r) way to inject the ViewEngine into the BaseController. It’s now injected through a public method using a MethodInjection attribute:

Thanks to this method, we no longer have pre-register all the Controllers with our container (in the previous version of jQueryMvc I scanned all dll’s on ApplicationStart to register the Controller and assign the ServiceViewFactory as the default ViewFactory)

Furthermore, since the ASP.NET MVC team decided to change the way the Views are rendered (now through a ViewEngine, which is nice I think), it was no longer needed to use the code from Aaron Lerch. Though still inspired by his code ofcourse, I removed almost all of his code now. We now have a single ‘ServiceViewEngine‘ inheriting from the ASP.NET MVC’s default WebFormViewEngine. All code deciding what view to render, is now located in this class.

What I did not like about preview 2, is that the name of the master-template cannot be set from within the ViewEngine. It’s now stored into the ViewContext, and the setter is private . So now the mastertemplate is set in the BaseController, causing the BaseController to have to know what type of request the current one is (which is bad):

As usual, you can download the hottest source from the Subversion repository at http://code.google.com/p/jquerymvc/source/checkout or you can download a zipped package of the source code.

A view days after I created my sample project that added some jQuery magic to the ASP.NET Mvc Framework, Aaron Lerch wrote an interesting article.

He used a ViewFactory to do the json-serialization and added XML serialization as well. I liked this approach better then using masterpages. I took his code, altered some bits and created a library called jQueryMvc with it. This library also utilizes the MvcContrib project. It’s now even easier to make your ASP.NET Mvc project ajax-enabled with jQuery, it just requires 4 steps:

1. Add a reference to jQueryMvc.dll
2. Make your global.asax inherit from JqueryMvcApplication
3. Add <%= Ajax.RegisterJqueryMvc(Page.ClientScript) %> to the <head> section of your (master)pages.
4. Let your controllers inherit from BaseController

That’s it, your all set. You should take a look at the SampleSite that’s included in the download on how to use the utility. Using it works almost the same as the previous version, so if you haven’t done so, you should read my previous article. The only difference is the exception handling. Since I decided to embrace the MvcContrib project, the exception handling for ajax & html requests have changed. Exceptions are now handled with a [Rescue] attribute. The BaseController has a default Rescue attribute attached which leads all exceptions to the "error.aspx" rescue handler. So your project should at least have /Views/Shared/Rescues/error.aspx that outputs the exceptions for your site. If you want to catch specific exception for yourself, you can add a rescue attribute to your site that catches that error type. E.g. if you want to catch a SecurityException, you could add

If an exception of type SecurityException is thrown during a controller action execution in your HomeController, MvcContrib will look for /Views/Home/Rescues/security.aspx and if that doesn’t exist, it will look for /Views/Shared/Rescues/security.aspx. The viewdata for those pages will be the exception itself. The rescue attribute can also be used on method level.

Another nice thing is that the MvcContrib is build to use Inversion of Control (IoC). BUT!: if you don’t want to do anything with IoC for now, you can leave it where it is! jQueryMvc just uses it for attaching the ViewFactory to your controllers, that’s all you need to know. You can also stop reading just here, the rest is about the dependency container that I used.

For jQueryMvc I choose the Microsoft Objectbuilder framework for this, although, with MvcContrib, you’re free to choose an other framework. I choose the ObjectBuilder, since I’m the one that committed that to MvcContrib

In JqueryMvcApplication, when the application get’s initialized, we’re looking for all controllers in the currently running project.

All these controllers are registered with the Dependency container and our custom ViewFactory is also registered with this container. The ObjectBulderControllerFactory makes sure the controllers are fetched through that very container, and when that happens, the ViewFactory is attached to them.

There are also some  nice helper functions in JqueryMvcApplication, for making the registration of your own services/helpers/etc into the container a breeze.

I’ll talk about using the container in some other article sometime.

For now, have fun with jQueryMvc.

Downloads

• Project at GoogleCode
• Download source, binaries & sample project
• View online demo of the sample site

This is a bugfix release only, no new features are introduced.

Download here

Anyway, this is a nice moment to let you guys know what I’m working on atm. I’m currently busy with the API-provider of the project, and it’s coming along quite nicely. There’s no need to check out the code from tigris yet, it’s really useless in the current state! I’ll ofcourse let you know when 0.1 alpha version is ready!

The project description:

Mission

The mission of Perry is to create a backwards compatible ‘web 2.0′ framework, utilizing the PEAR repository as much as possible.
Perry will provide you with a MVC framework for PHP with all modern ‘web 2.0′ features build on-the-fly ™.
The model part is handled with the DB_DataObject library,
the views are XSLT and the controller is perry itself.

All public functions of your application will be made available to other developers through a wide set of API’s.
Currently the developers can choose between SOAP, REST, XML-RPC, JSON, HTML (partly or entire page).

If the client doesnt support javascript (or to be more specific: xmlhttprequests), we’ll fall back to plain HTML output.
No extra work required! Everyone can view (or crawl!!) your site, it’s just that without the jscript the user will
have to deal with some less functionalities, but the content will be available.

Although inspired a little by Ruby on Rails, it won’t look like it by far.
Perry stands all by itself, it’s PEAR on rails

What is the scope of this project?

• KiSS
• Build a web 2.0 framework
• Keep a small and simple base to work with. No predefined applications, just a framework
• PEARalize!

Current features

• No-extra-work-required-api accessible through SOAP, REST, XML-RPC, JSON and HTML.
• XSLT templating.

So what’s all the difference then….

• Superb scroll feeling… it looks just real
• We can still produce any HTML, in stead of fixed table-rows
• We now have XSLT support!!! I’m really happy with this one. It allows to have
  any xml source as dataset for the grid. Just before it gets placed into the grid for viewing, you can do some xslt magic on it. Just have a look at the source of the yahoo demo to see how it works. This demo will take the literal html of the yahoo-api and gets parsed by our own xslt.
• Auto-size. the livegrid can automatically do calculations and resizing if the grid is empty on forehand. This way your HTML page doesn’t need to know the exact row-size that will be returned by the
• In stead of keeping a set of rows in the buffer, we keep the xml-source in the buffer, and any newly loaded source is merged with the first one. For merging that is not-standard, you can specify an xpath to select the rows that should be buffered & used for display.
• And ofcourse, last but not least, the reason why I started the fork in the first place: the scrollwheel support!

The sources, demo’s etc can be found at:

• The grid’s javascript
• The most basic demo, loads html through ajax
• The serverside script that delivers the HTML for the simple demo
• The yahoo demo!
• The yahoo xslt
• the prototype script that is required

Enjoy!