LA.NET [EN]

Nov 09

Well, this really doesn’t deserve any special attention. Ok, let me put it another way: there’s a lot of work going on behind the scenes, but you shouldn’t have to worry with any of it.

I’ve thought about writing a post on the objects that end up being used by the AdoNetDataContext to propagate changes back to the server, but after some thought, I’ve give up on that idea because I’m not seeing anyone use any of these classes directly (yes, the AdoNetDataContext should do it all for you).

And that’s why I’m wrapping up this series on MS AJAX preview 6. I hope you’ve enjoyed it as much as did…Now, I do need to find another topic to keep me busy looking at new stuff…any ideas?

12 comments so far

  1. william apken
    11:52 pm - 11-9-2009

    Great job. Sorry to see it end.

  2. william apken
    11:59 pm - 11-9-2009

    I would like to see authentication services provided by MS Ajax. How they work with the AdoNet Data Service and RESTful services.

    If I understand it correctly, you can set permissions when you create the AdoNet Data Service.

    Then base upon permissions granted, AdoNetDataServices will only return the items that this user has permission to view.

    I have not tried this yet. I”m not sure, but I think I saw this in a video by Pablo Castro. (this may not be his name, but I think it is close).

    Just an idea.

  3. Scott Wade
    12:44 am - 11-10-2009

    And idea for a topic…is something I”m not finding very much information on yet: How to correctly incorporate custom scripts for use with the new Script Loader in the Microsoft Ajax Library Preview 6, and related, how to both load and use the Ajax Control Toolkit scripts-only through the Script Loader and the exact syntax needed when using Sys.require() for each of the controls, with examples being used with Preview 6 using imperative syntax instead of any declarative syntax.

  4. luisabreu
    12:53 pm - 11-10-2009

    William, i think that should “just work”. doesn”t it?

    Scott, I think that you should wait a little more because I expect that the ACT will be added in the near future. In other words, I expect that when MS AJAX is released, we”ll have the client files for ACT updated so that they can be used with the script loader. If you can”t wait, then I think I”ve written a post that shows what you need to do do adapt your script files so that they can be used by the script loader. You”ll have a little bit of work though because you”ll have to get the ACT client files dependencies right…

  5. william apken
    3:34 pm - 11-10-2009

    Access to all ACT would be cool for sure.

    I have not tried to use the MS Ajax ApplicationServices yet. So I don”t know.

    Still putting the final touches on my dataView implemented as a component.

    My next step will be trying to implement a formComponent and the first case I want to test is a login form that require no postbacks.

    Then on to my question about integration of authentication and AdoNetDataContext.

    Do you think we will see a preview 7 or will we finally get a beta?

  6. Andy
    6:02 pm - 11-10-2009

    Great series. Have followed your hints to use the new DataView.

    I”m having problems using the JavaScriptSerializer with data from DataView.get_data() with nested DataViews, as proxy properties on the model data such as __msajaxbindings and __msajaxdispose cause circular references.

    Have you come across this? What”s the best way to get the JSON raw output from nested DataViews? As I”m using jQuery.ajax requests, not the DataContext/Proxy.

  7. luisabreu
    9:00 pm - 11-10-2009

    William, I”m almost positive that you can simply apply asp.net security to your services and everything should just work out.

    Andy, can you be more specific? The properties you mention end up being added to the HTML elements, not to the data…Can you build a small demo and put it here? or send it to me by mail and I”ll try to take alook…

  8. Andy
    10:34 pm - 11-10-2009

    Hope the below formats OK! Thanks for any help.

    Nested templates:

    Title

    Body
    {binding body}

    Save

    JSON:

    var instance = { title: ”New document”, content: { sections: [ { body: ”Enter text here” } ]};

    Init:

    var view = Sys.create.dataView(“#maincontent” , { itemTemplate: ”#edit”, data: instance});

    The problem:

    When view.get_data() is called, each of objects in the “sections” array have __msajaxbinding and __msajaxdispose properties. This means that Sys.Serialization.JavaScriptSerializer.serialize(view.get_data()) fails, complaining of circular references.

    Am I binding the “sections” incorrectly?

  9. luisabreu
    9:57 am - 11-11-2009

    Oh, the bindings…right 🙂

    You”re absolutely right here. The only thing I can think of is cloning the objects without using the __ms props…I”m saying this because it looks like the client serializer will always serialize everything by default and it seems like there”s no way to pass a list of non-serializable props…

  10. luisabreu
    10:00 am - 11-11-2009

    btw, one more observation: why are you putting a form inside the template?

  11. Andy
    1:40 pm - 11-11-2009

    Yes, the form element isn”t needed. It”s as I was testing out JSON and traditional HTTP Post payloads. There are multiple edit templates on the page.

    It”s still tricky trying to clone the data object, or at least in a generic way for any entity type, as the quick way to clone the data object I tried via jQuery.extend(true, {}, view.get_data()) similarly errors due to the circular references from the __msajaxbindings.

    Yes, it certainly would be good in the Microsoft Ajax Library to have either JavaScriptSerializer or a (deep) clone method that take a list of properties to ignore.

  12. luisabreu
    2:33 pm - 11-11-2009

    Yes, writing it in a reusable manner is not that easy…I guess you could always reproduce the serialization code used by the serializer and adapt it so that it doesn”t copy the properties…