Deserializing derived objects

Hello!

Maybe my question is rather stupid, but I'm just a newbie...

I have some classes derived from class DataObject, for example Account:

public

classAccount :DataObject {...}

and a [ScriptService()] - marked .asmx service with method

[

WebMethod( EnableSession =true )]publicDataObject AddObject(DataObject dataObject )

which passes this dataObject to another .svc service which writes it to database...

I call AddObject method throughSys.Net.WebServiceProxy.invoke(...), passing JavaScript object corresponding to Account class (I mean it has the same fields). If I set the parameter type in AddObject method to Account - everything works fine, it serializes and deserializes correct and passes further as an Account object. But if I try to set parameter type to DataObject - it looks like deserializer cuts all fields that are not declared in DataObject class and doesn't recognize derived object. The dataObject object in this method is pure DataObject, not Account.

I want to handle objects this way because actually I have now something about 10 classes and 10 such methods, and their number may increase. Writing all methods like AddAccount, AddUser, AddQuote and so on looks unhandy for me.

Is it possible for default JavaScriptSerializer to recognize derived objects? Or if I have to redefine it - how could I do that?

Thank you!

I faced a similar problem. The issue at hand is that the module that does the serialization/deserialization will look to the return types and parameters as cues for what it should serialize to / deserialize to , and it doesn't look deeper than that. I ended up doing a fairly hacky work-around to get the code in on time, but at some point I'm probably going to try and figure out a good solution.

A couple thoughts I had, neither of which are tried out. First, I'm aware that you can generate javascript types for nested types of the web service class (seehttp://ajax.asp.net/docs/mref/T_System_Web_Script_Services_GenerateScriptTypeAttribute.aspx) so that's an option, I suppose. Seems like not the best solution in our case, though, as what we're working with aren't logically nested types of the web service. I also considered writing a serializer module that can take the first param as a type argument so that, at the least, you could specify which concrete type you're sending upstream.instead of letting the module map only to the types in the webmethod params.

For XML Serialization (as used in classic 2.0 asmx web services) there is an attribute called XmlInclude which allows you to specify specializations of the actual return type. omly the ones you list with XmlInclude will be taken into account by the XmlSerializer.

I know the script service infrastructure hooks into the classic asmx stuff, but I have no idea if it looks at XmlInclude-s to. You might give it a try ...

-- Henkk

Derived Textbox Not Recognized as Textbox

Hi All,

I have a derived text box class that inherits directly off of TextBox. I have this textbox on a page, and when I use the TextboxWatermark extender and set the TargetControlID to my textbox's ID Atlas doesn't seem to realize that it's a textbox, but just a control. We surmised this because the extender throws an error on "this.control.get_text();" while it's happy to execute "this.control_getCssClass();"

If I use a regular ASP textbox on the page, the extender is a happy camper. Anybody have any thoughts about this?

Thx.

I am having the same issue with the toolkit samples as well. Did you find a fix or reason for this? I also do not have any the properties available in the property box in VS2005 for any of the Atlas controls. But I can go to the source and enter the properties fine.

Dale

We haven't gotten an answer yet. I'm going to try another avenue and see if I get anywhere. I'll post any results.

Oh man, I can't believe I screwed that up. We added code that checks the type of the control being extended and then tweaks the generated XML type based on that so the client side can talk to the specific type (e.g. Sys.UI.TextBox instead of Sys.UI.Control). Well it looks in a hashtable based on the type of the control. So if they type isn't exact, the lookup fails. Darn.

Anyway, here's how to work around it. You just need to do a simple override of the TextboxWatermarkExtender. If VS starts complaining about the reference to ExtenderControlBase, click on "Microsoft.AtlasControlExtender" in your reference and change "Specific Version" to true. I'm not sure why mine got angry about that, but just in case you see it.

public class MyTextBox : System.Web.UI.WebControls.TextBox { }public class MyTextboxWaterMarkExtender : AtlasControlToolkit.TextBoxWatermarkExtender {protected override string GetClientClassForControl(System.Web.UI.Control control) {if (controlis System.Web.UI.WebControls.TextBox) {return"textBox"; }return base.GetClientClassForControl(control); } }

Hey Shawn,

Thanks for the work around. We'll get to testing it this afternoon.

It's a sweet toolkit and the bugs (aka job security) will get worked out.

Debugging Web Service/Atlas

Hello,

I'm trying to debug a problem with a biz layer class that gets called from my web service. I rtied doing System.Diagnostic.Debug.writeline but nothing gets written and also tried doing breakpoints but those don't work either. Is there anything I can do to get debug info?

Thanks,

Clank

PS - I don't the search function works for the forums either.

Yeah, debugging Ajax style applications is tough. Basically you have to put a debug line at the start of your web service and make sure it even gets there. If not, start with "alerts" in the JavaScript before your web service is called.

You can attach a debugger to both the server-side and the client-side (provided you unchecked the two relevant checkboxes in IE advanced settings).

You can also use debug.dump and debug.trace from the client-side.

You can also use Nikhil's browser helper to monitor the network traffic and get client-side stack traces:http://www.nikhilk.net/Project.WebDevHelper.aspx