ouch, totally missed that one.
Thanks!
Printable View
ouch, totally missed that one.
Thanks!
Ext.Direct.Mvc v0.8.1 is released.
The download link is in the first post of this thread.
Changes:I have also removed the Ext JS source from the test application and instead linked the scripts from cachefly.net. The package is now much smaller.Code:* Remove: Interception of every exception introduced in v0.8.0 (was a bad idea).
* Added: DirectHandleErrorAttribute class which can be used to mark a whole
controller or an individual action with a [DirectHandleError] attribute to
intercept all exceptions and return a direct response of type "exception"
that contains the information about the exception.
* Added: DirectException class for throwing custom exceptions that will always
return to the client as a direct response of type "exception".
* Added: Suport for ActionNameAttribute. If an action is marked with this
attribute, then the specified name will be used when generating API and for
routing direct requests. Make sure that you use the name specified in this
attribute when calling the method from your JS code.
* Added: New overloaded methods in DirectController. Check out DirectForm().
* Renamed: exceptionData to errorData.
* Fixed: Serialization of DirectResponse in file upload mode.
* Misc: Other minor fixes and code optimizations.
Thanks to the .NET expert and my colleague aritchie for pointing out the issues with catching all exceptions.
Uploaded Ext.Direct.Mvc v0.8.2.
See the first post of this thread for the download link.
Changes:Code:* Fixed: Binding DateTime, Enum, Guid and nullable types.
* Misc: Lots of unnecessary code was removed.
It seems with latest I have problems with passing GUID strings into server-side code. Earlier with version 7 I was able to invoke controller methods that had Guid parameters - now it is broken.
Same problem with DateTime, from JS I pass Javascript's Date type variable, on server I'm getting string representation, but your code in DirectMethodInvoker.GetParameterValues doesn't correctly handle this. It compares String to Nullable<DateTime> that i obviously wrong.
I think better would be to allow reflection do the job. Just handle JSON object deserialization, do not check types yourself.
On client I have simple string like "22F70AFA-D92F-418d-AED5-12AB5C067162", on server my controller method signature in like method(Guid? itemId). I'm using Nullable<> because Guid is value type and it cannot be null.
On first look I can suggest the following changes, but I believe all other attempts to use Nullable<> type found fail same way. So probably better not check types at all.
Code:if (pType == typeof(Guid?))
{
try
{
rawValue = new Guid?(new Guid(rawValue.ToString()));
vType = typeof(Guid?);
}
catch
{
}
}
if (pType == typeof(DateTime?))
{
try
{
rawValue = new DateTime?(DateTime.Parse(rawValue.ToString()));
vType = typeof(DateTime?);
}
catch
{
}
}
if (!vType.Matches(pType))
{
throw new ArgumentException(String.Format(DirectResources.DirectMethodInvoker_WrongArgumentType, pType.FullName));
}
if (pType != typeof(Guid?) && pType != typeof(DateTime?))
{
if (pType.IsEnum && vType != typeof(string) || pType != typeof(JObject) && pType.IsComplexType() && !pType.IsEnum)
{
// for objects, arrays and enums (numeric value)
rawValue = JsonConvert.DeserializeObject(rawValue.ToString(), pType);
}
}
sergeime
Thanks for the bug report. I have updated version 0.8.2. Can you please download it again from the first post and try? Let me know if you're still having those issues. Thanks.
Thanks for the bug report.keep up posting.thanks
________________
Advertising
First off, thanks for your contributions to the ExtJS community. It's people like you who make ExtJS such an attractive library by helping it keep pace with the ever changing technical world around it. That being said, I myself am having a hard time keeping pace and need a little knowledge nugget in regards to ExtJS, Direct, and ASP.NET MVC. I know you're busy, so answer when you can.
I have been working with ExtJS for over a year now and love it, it's re-energized my programming efforts :) I use ExtJS obviously to generate the client side of my app, which currently uses the traditional (2.2) Ext Ajax Request framework to call into my server side to get the data it needs. My server-side is comprised of HttpHandler files that are specific to the module that is doing the request, therefore, even though I have the "normal" one page aspx application, I have many HttpHandler files (implemented as IHttpHandler ASHX files). While I don't really have a problem implementing my own "routing engine" in these ASHX files to send the client call to the correct class and method, I totally see the benefit of Direct to reduce the amount of client side code, enable the "direct" calling of server-side methods, batching of requests, etc.
However, my question at this point is why use the ASP.NET MVC design pattern as the destination point for the ExtJS Direct calls vs. using the .Net Direct Router implementation? I noticed that you were one of the initial posters in the the Direct Router forum but soon disappeared only to produce your MVC implementation soon thereafter. That makes me think you had a light bulb moment, or saw something that "routed" you this way. I also see Dave Sanders appearing in this MVC forum now who seems to be a huge contributor to the .Net Router project so that even makes me more curious as to the benefits of one approach over the other. Just to be sure, I am totally clueless right this moment on the MVC pattern so please excuse me if the answer is obvious, but I would love to know what benefits the MVC pattern provides over the initial .Net Router, if any? Is this simply two ways to skin the same cat (sorry Peta)?
I am downloading your project now and will be studying it....thanks a ton for any directional help!