Ext.Direct .NET Router

[Gunmen]

UPDATE!

New router is out, the link in the first post has been updated.

Thanks for the update and support! I'm going to start immediately.

[mbajema]

Great work! I was able to seamlessly replace the version I had hacked away at to make it work for my needs with this new version and it worked perfectly. I'm happy to be using the pseudo-official version of the .NET router now.

[Gunmen]

@Evan, I receive an js error in IE (Id, string or number is expected) when opening the Grid and Form examples. However, the examples do work in Mozilla Firefox. I'm running the examples with the Visual Studio .NET web server.

Anyone else having this problem?

UPDATE: For IE, you need to remove the comma after 'direction: 'ASC',' in all js files in the Grid directory and the comma after 'company: 'Ext',' in the form.js file in the Form directory. (Big up to myself )

Thanks!

[evant]

Ah, duh. Didn't test it on IE. I'll fix this up.

[evant]

Thanks guys, got it updated.

[lauralxj]

Firebug Infomation:

{"action":"Method","method":"GetTrees","data":["0",{"param1":"value1","param2":"value2"}],"type":"rpc"
,"tid":2}

SERVER Method

[DirectMethod]
        public JArray GetTrees(string ID,Object obj)
        {
           //HOW TO GET obj's Values
        }

please tell me how to do!Thanks!

[evant]

By default it parses it as a dictionary, check it out using the debugger.

[codeable]

I have been trying out your implementation and I generally like it. I have two questions/feature requests. (I will do them myself if needed).

1) [Minor]
---------------------------
Add an id to the provider to simplify JS access to the provider.
In JavaScript It would be nice to be able to do:

Ext.Direct.getProvider(id);

I have been adding the id myself, quick and dirty like so:

 
Namespace.To.Handler.id = "Namespace.To.Handler";
Ext.Direct.addProvider(Namespace.To.Handler);

Likely place to implement it is:

 
//Ext.Direct.DirectHandler::ProcessRequest
 
provider = new DirectProvider()
{
     Name = this.ProviderName,
     Url = context.Request.Path,
     Namespace = this.Namespace,
     Timeout = this.Timeout,
     MaxRetries = this.MaxRetries,
     AutoNamespace = this.AutoNamespace,
     ID = this.GenerateID(); // or something similar.   <-------
};

2) [Major]
---------------------------
Add the ability to inject/autoprocess/overwrite meta data along with the requests. Let me try to explain without the meta data injection, then the proposed solution with the injection. (this example is a bit contrived for demonstration purposes)

Assume I have method:

GetCurrentView(Guid clientInstanceToken);

This method simple returns the name of the current view for a particular browser window instance(same session). The client calls this from JS using its direct provider and passes in some guid that it created when the page was first loaded. This allows the user to have multiple pages open within the same session but render different results.

In the current architecture, one simply has to add the clientInstanceToken to every method to make this work. I would like to have the ability to add this functionality "behind the scenes"; that is, inject the parameter clientInstanceToken to all methods with (perhaps) the MetaDataParameterAttribute("clientInstanceToken") like so:

 
[DirectMethod,MetaDataParameterAttribute("clientInstanceToken")]
public string GetCurrentView(Guid clientInstanceToken);

or

 
[DirectMethod,MetaDataParameterAttribute("clientInstanceToken")]
public string GetCurrentView();

Then the direct provider can add the new metadata parameter to the Ext.Provider instance it creates along with a mechanism to retrieve its value. This could be a simple function in JS that the consumer must process:

 
Ext.Direct.getProvider(id).acquireMetaData = function(args){ //return the metadata here;
}

There are many ways to "present" the meta data to the DirectAction instance, here are a few quick ideas:
1) If the parameter "clientInstanceToken" exists, then simply populate it with the value.
2) If the parameter does not exist, have a dictionary in the DirectHandler that contains the metadata values for the current request:

 
base.MethodMetaData["GetCurrentView"]

With this type of functionality, any method could contain meta-information that can be applied in an aspect oriented way. Which makes security, identification, concurrency, etc much simpler to implement.

Let me know what you think, I will likely be integrating these ideas sometime next for my next project, so hopefully I hear something before then!

[evant]

1) Easy enough, sure.

2) Interesting idea. The problem is that I can't just implement it in the .NET router. It would actually require changes to the framework to allow the acquisition of the meta data.

[codeable]

I agree that some injection/non-supported code would be required for it to work on the client side. (therefore the feature would be tied to specific versions of Ext) But all in all, it can be done without touching the Ext libraries and would only need to be updated if the Ext.Direct plumbing changed. We don't need to add additional features, we only need to inject parameters before its sent to the server, then strip those back out before presenting it to .NET.

In fact, I have a working example of the client side fully functional without the .NET portion. I simply respond to the "beforecall" event and add the metadata parameters there. It currently works fine with or without the parameter specified:

 
Path.To.GetCurrentView("GUID-VALUE-HERE",function(data, trans) {
     // Process Results
});
Path.To.GetCurrentView(function(data, trans) {
    // Process Results
});

The only issues I found while making this work was the callback was lost when all parameters are not specified. I simply recreated the callback after injecting the proper parameters and all works well.