Ext.Direct for ASP.NET MVC

[elishnevsky]

Hi!
At first, thanks for your work!

I need some advice or sample of using your implementation with polling provider, of course if you already have something specially for this? Now I'm creating new polling provider and it repetitively makes post requests to the action.

Polling provider doesn't require any server-side stack implementation. Check out this sample.

[isit.gd]

hi

i need to return a download of an excel doc from a controller method.
the scenario is that if the store is refreshed with an export flag, instead of returning json of the data i need it to return an excel doc instead - is that possible wiht this?

cheers

w://

[elishnevsky]

hi

i need to return a download of an excel doc from a controller method.
the scenario is that if the store is refreshed with an export flag, instead of returning json of the data i need it to return an excel doc instead - is that possible wiht this?

cheers

w://

No. Do it separately.

[Dave.Sanders]

Hey there, I've been using (and modifying) the traditional ASP.Net router for a while now, but am doing a new MVC project so I grabbed your code. One struggle I had, who's resolution might be useful to others, and one suggestion:

1. Struggle: I kept getting errors talking about how 'WriteJson' is not implemented in Ext.Direct.Mvc.RequestDataConverter. So, nothing was getting deserialized when I passed it up to the server. BUT, the test app included in the zip worked fine. Turns out that my Newtonsoft.Json was a 3.5 BETA, not the version that is being used by Direct.Mvc or in the test app. So, when it went to serialize, some changes between my version and your version of Newtonsoft caused epic failure. Easy to fix: if you are referencing the Newtonsoft.Json DLL in your project before hand - make sure you get up to date with the version that this code is based on.

2. Suggestion: It would be nice if the router would complain if the number of parameters sent in on the request don't match what the controller action accepts. I was fighting a "WTF?" bug today and it was because I had one extra parameter in my call. So, Ext.Direct was trying to assign my callback to a variable - not very helpful.

Probably more to come as I dig into it, but nice job!

[elishnevsky]

Hi Dave,

1. Like any software that is compiled with a third party dll, my implementation of Ext.Direct for MVC is compiled with a specific version of Json.NET library and hence I cannot guarantee that it will work with a different version. This is why I include Json.NET dll in the bin folder together with my dll. In the next post I will announce the release of the next version of Ext.Direct.Mvc which is compiled with the very latest version of Json.NET. Please check it out.

2. As a matter of fact the router does complain about it - an exception of type DirectException is thrown and a direct response with type 'exception' is returned to the client. In my applications I always add the following code:

Ext.Direct.on('exception', function(e) {
    if (window.console) console.error(e, e.message);
});

And of course I always have firebug open

[elishnevsky]

Uploaded new version Ext.Direct.Mvc v0.7.

Latest changes:

* Added: support for passing one-dimensional arrays of simple as well as complex types
* Misc: compiled with Json.NET 3.5 Release 5 released on Sat Oct 10 2009 at 3:00 AM

Please test and report bugs.

To download see the first post of this thread.

P.S. Thanks to maxigroovy for help with arrays.

[Dave.Sanders]

On number of params not matching, I will test again - my js side is in flux and I might have missed it.

Speaking of error handling, I have a simple suggestion to add an optional param of Data to DirectException. This would be any object the user wants to pass to the front-end. I need this because I pass forward some extra info on the exception so that the user can make a comment on what they were doing to give me some extra debugging info.

It's a very simple addition for a (imho) lot of benefit. I've included the updated class below. You also need to make changes to DirectResponse, which I've included snippets of too.

DirectException

 using System;

namespace Ext.Direct.Mvc
{
    public class DirectException : ApplicationException
    {
        public object Data {get; set;}

        public DirectException() { }

        public DirectException(string message)
            : base(message) { }

        public DirectException(string message, object Data) : base(message) {
            this.Data = Data;
        }

        public DirectException(string message, Exception innerException)
            : base(message, innerException) { }

        public DirectException(string message, Exception innerException, object Data) : base(message, innerException)
        {
            this.Data = Data;
        }
    }
}

DirectResponse:

        public DirectResponse(DirectRequest request, DirectException exception)
            : this(request) {
            this.Type = ResponseExceptionType;
            this.ExceptionMessage = exception.Message;
            this.Where = String.Format("{0}.{1}", request.Action, request.Method);
            this.Data = exception.Data;
        }

and

        [JsonProperty("data", NullValueHandling = NullValueHandling.Ignore)]
        public object Data
        {
            get;
            set;
        }

[elishnevsky]

In fact I did think about doing this but was stopped by the Ext.Direct Remoting Specifications that says the following:

If an exception occurs on the server-side the router should also return the following error information when the router is in debugging mode.

* type – 'exception'
* message – Message which helps the developer identify what error occurred on the server-side
* where – Message which tells the developer where the error occurred on the server-side.

This exception handling within the router should have the ability to be turned on or off. This exception information should never be sent back to the client in a production environment because of security concerns.

Exceptions are meant for server-side exceptions. Not application level errors.

In my implementation I tried to follow the spec how I understand it, although I am not sure if I understand it correctly.

For dealing with application level errors you can always catch exceptions in your controller action, build some custom error object, return it as if it was a regular data object and handle it properly on the client. Something like this:

public ActionResult MyAction() {
    try {
        // you main action logic here, such as data retrieval etc.
        return Direct (data);
    } catch (Exception ex) {
        var errorObj = new {
            success = false,
            error = "You specific error message here...",
            data = some_additional_data_object
        };
        return Direct(errorObj);
    }
}

To check for server-side application exceptions on the client globally you could do something similar to this:

Ext.Direct.on('event', function(e, prov) {
    var r = e.result;
    if (r.type == 'rpc' && r.success && r.success == false) {
        alert(r.error);
    }
});

Perhaps additional logic is needed. Haven't tested myself. I don't have global server-side error handling on the client in my applications.

[Dave.Sanders]

Well, I think it should be there, they should at least specify an optional data element. I personally think an optional, non-default data attribute wouldn't kill anything. Its helpful if you need more data than just where and message.

The reason I need it to come across as an exception is because then I can easily bind an event to it via the Ext.Direct.on("exception"). This way all exceptions go to the same place in my JS code.

I missed that Exception already has a data object, so its even easier. Here are the real changes that would need to happen - no changes to DirectRequestException needed.

DirectResponse:

public DirectResponse(DirectRequest request, Exception exception)
            : this(request) {
            this.Type = ResponseExceptionType;
            this.ExceptionMessage = exception.Message;
            this.Where = String.Format("{0}.{1}", request.Action, request.Method);
            this.Data = exception.Data;
        }

DirectProvider - change the catch in ExecuteRequest to catch on all exceptions - not just DirectRequestExceptions.

  } catch (Exception exception) {

Then Data is a dictionary on your exception to add data to. What I do on the server side is have all of my controllers inherit from a common class, then catch OnException to alter the error data on the way out. Works well.

If you don't decide to include this because of their spec, then that's fine. I'll just fork my own - but I figured it might be useful to someone else.

[elishnevsky]

I don't think that catching ALL exceptions in DirectProvider is a good idea. I prefer application level exceptions to bubble up to a controller action from any layer.

Perhaps I should have made it more clear, that DirectException is a public class and you can throw an exception of this type from anywhere in your code by simply doing

throw new DirectException(errorMsg);

DirectException class inherits Data property from ApplicationException class, so if you want to set it, you can do it:

throw new DirectException(errorMsg) {
    Data = myData
};

Mind that type of Data property is IDictionary, so it can't just be any object.

I guess I should revisit error handling and provide an easier way to deal with exceptions. Let me have a think