There doesn't as far as we know exist an easy way to call ASP.NET page methods from prototype.  One way to get around this is too rewrite the prototype AJAX object base function and add a new property called datatype:

Ajax.Base = Class.create({
    initialize: function(options)
    {
        this.options = {
            method: 'post',
            asynchronous: true,
            contentType: 'application/x-www-form-urlencoded',
            encoding: 'UTF-8',
            parameters: '',
            evalJSON: true,
            evalJS: true,
            dataType: 'string'
        };
        Object.extend(this.options, options || {});

        this.options.method = this.options.method.toLowerCase();

        if (this.options.dataType == "string")
        {
            if (Object.isString(this.options.parameters))
                this.options.parameters = this.options.parameters.toQueryParams();
        }
    }
});

Then rewrite Ajax.Request request function to:

    request: function(url)
    {
        this.url = url;
        this.method = this.options.method;
        var params;

        if (this.options.dataType == "string")
        {
            params = Object.clone(this.options.parameters);

            if (!['get', 'post'].include(this.method))
            {
                // simulate other verbs over post
                params['_method'] = this.method;
                this.method = 'post';
            }

            this.parameters = params;

            if (params = Object.toQueryString(params))
            {
                // when GET, append parameters to URL
                if (this.method == 'get')
                    this.url += (this.url.include('?') ? '&' : '?') + params;
                else if (/Konqueror|Safari|KHTML/.test(navigator.userAgent))
                    params += '&_=';
            }
        }
        else if (this.options.dataType == "jSon")
        {
            params = this.options.parameters;
        }
        try
        {
            var response = new Ajax.Response(this);
            if (this.options.onCreate) this.options.onCreate(response);
            Ajax.Responders.dispatch('onCreate', this, response);

            this.transport.open(this.method.toUpperCase(), this.url, this.options.asynchronous);

            if (this.options.asynchronous) this.respondToReadyState.bind(this).defer(1);

            this.transport.onreadystatechange = this.onStateChange.bind(this);
            this.setRequestHeaders();

            this.body = this.method == 'post' ? (this.options.postBody || params) : null;
            this.transport.send(this.body);

            /* Force Firefox to handle ready state 4 for synchronous requests */
            if (!this.options.asynchronous && this.transport.overrideMimeType)
                this.onStateChange();

        }
        catch (e)
        {
            this.dispatchException(e);
        }
    },

You can now call:

    new Ajax.Request(pagePath + "/" + fn, {
      method: "POST",
      contentType: "application/json; charset=utf-8",
      parameters: paramList,
      dataType: 'jSon',
      onSuccess: successFn,
      onFailure: errorFn
    });

With a purely JSON compatible parameter set, i.e. parameters : {'start':'1','end':'1'} will now be treated as a complete string by the ASP.NET page as prototype will no longer mangle your JSON.

Bingo!

We recently undertook a project to supply a web app with handheld device functionality.  As is the case with these things we needed to share the Business Objects between the web app and each handheld device. 

For anybody looking at doing this start here: http://msdn.microsoft.com/en-gb/magazine/cc163387.aspx

The quick (and simple) way to share assemblies is to create a CF class library, copy the .csproj file to your existing Full Framework 'Business Object' project folder, edit the copied .csproj file with notepad and then add the codefiles you want to share to this new class library.  You then add any relevant compilation symbols to the code so that what isn't relevant to the CF won't make you code explode in a mess of sprockets and shrapnel.

You then just need to add a reference to the newly moved .csproj file in your mobile project and thats it.  From now on any changes in the FF Business Object classes are reflected in the CF Business Object classes (because they are the same files) and vice versa.

Simple.

The realtionship started off well.  Now were undergoing a messy divorce.

Nhibernate - it seems to answer so many problems.  Unfortunately it creates a whole slew of new ones.

For anyone embarking on building SERIOUS applications then beware, it ain't a silver bullet to the problem of OR impedance.  Soft deletes in most applications (especially financial applications that we do) are often a big requirement (the FSA is a hard taskmaster).  NHibernate just can't cope with these.  Well, thats not strictly true - it can cope as long as you dont have ternary relationhips between objects, if you do, then your stuffed.

The recomended way is to hook into the delete event listener, which you can, but it will leave your relationship tables untouched and when you do a select then your 'deleted' object will arise 'a la Lazarus' to make you like like a clown to your clients.

Thankfully been a bunch of geniuses we rolled our own OR solution which will work on the web, pda's and the desktop and it fits into a lovely dll.  NHibernate is a great idea and useful for basic apps but a poor implementation for serious development.

Avoid.

A first post just to describe how this blog will work.  Predominantly its going to be a place to discuss what we at Sapere find interesting in the world of .NET, development and all its associated convuluted bolt ons and functionality.  At the moment were very interested in NHibernate and its application within enterprise apps. 

After initially using our own home rolled OR Mapper for the last 6 months we needed more functionality; and like any sensible developers decided not to reinvent the wheel.  We've found NHibernate, so far, to be powerful, full featured and most of all intuitive to those with an understanding of the underlying .NET framework.

The predominant problem with NHibernate is bad examples, out of date advice and a learning curve shaped like the Eiger. Hopefully forthcoming posts will remedy this...

More posts to follow with source code examples.