Ask a questionAsk a question
 

AnswerDataBinding Complex Type properties

  • Saturday, May 24, 2008 2:33 PMJulie LermanMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

     

    I've been playing with Complex Types in databinding scenarios.

     

    Let's use this example :

     

    Contact

      firstname

      lastname

      Address (complex type)

          street

          city

          state

     

    When I create an EntityDataSource that points to an entity with a complex type, it surfaces the complex type's properties. E.g. if I bind the EDS to a datagrid, I can see as my grid columns:

     

    contactID

    firstname

    lastname

    Address.street

    Address.city

    Address.state

     

    However if I try to do databinding without the eds I'm hitting a wall.

     

    Example (which is not real world, just something to test out the functionality)

     

    dim mycontacts=context.Contacts.ToList

     

    with dropdownList1

     .DataTextField="Address.street"

    .DataValueField="contactID"

    .datasource=mycontacts

    .databind

    end with

     

    I have paid attention to case in the strings for binding.

     

    When I hit databind, I get an exception telling me that Contact does not contain a property with the name Address.street.

     

    In debug I can definitely get a value back if I request myContacts(0).Address.street.

     

    When trying this with a Windows Forms ComboBox using "Address.street" as the DisplayMember, rather than an exception , it displays the value member (contactid). If I use "firstname" as the DisplayMember, I get firstname.

     

    So what's the problem? Me again?

     

    thanks

     

    julie

     

Answers

  • Saturday, May 24, 2008 4:55 PMDiego B VegaMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    Hello Julie,

    I don't think you are the problem this time Wink

    There are different ways of specifying which property a databound control binds to in ASP.NET, like Eval() Bind(), BoundField.DataField, ListControl.DataTextField, etc. And in general, they behave differently.

    The flattening we did on EntityDataSource is an attempt to make the properties that are exposed by EDM entities available for 2-way databinding in most cases.

    For instance, in your example, we provide a property descriptor for customer.Address, and also for customer.Address.Street.

    At runtime, in the case of a control binding to Eval(“Address.Street”) from a customer, Eval will use the property descriptor corresponding to Address, and it will drill down on it to extract the value of the Street property on it.

    A grid column of a BoundField derived type with DataField = “Address.Street” will work differently: it will just look for a property descriptor in the data item with a name as “Address.Street”. In fact, EntityDataSource is the first DataSource control that I know off that will provide such a thing.

    Bind(“Address.Street”) will work in a similar fashion to Eval() when reading the properties into the data bound control, but will act a little bit more like BoundField when sending back changes to the DataSource.

    There are a few cases in which the behavior is not any of the above and hence you end up with a control that cannot have access to a complex type’s properties. You can expect us to work closely with the ASP.NET team in making the experience smoother in future versions.

    Also, in this case, I think it is worthy of mentioning, you have to consider that flattening of properties in the EntityDataSource only happen under certain conditions. You can take a second look at the rules of wrapping (which is the mechanism we use to obtain flattened properties) in this blog post.

    Besides, we worked very closely with the ASP.NET Dynamic Data in this release, to enable their technology to work EDM through the EntityDataSource. I think it is very worthy of trying.

    Regarding what you see in the Windows Forms ComboBox, we don't do any flattening there, and so there is no property descriptor for "Address.Street". The way to get it is to do an explicit projection of "ContactId, Address.Street AS Street", and then bind the control to that. This will actually also work for you in any ASP.NET ListControl.

    Hope this helps,
    Diego

All Replies

  • Saturday, May 24, 2008 4:55 PMDiego B VegaMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    Hello Julie,

    I don't think you are the problem this time Wink

    There are different ways of specifying which property a databound control binds to in ASP.NET, like Eval() Bind(), BoundField.DataField, ListControl.DataTextField, etc. And in general, they behave differently.

    The flattening we did on EntityDataSource is an attempt to make the properties that are exposed by EDM entities available for 2-way databinding in most cases.

    For instance, in your example, we provide a property descriptor for customer.Address, and also for customer.Address.Street.

    At runtime, in the case of a control binding to Eval(“Address.Street”) from a customer, Eval will use the property descriptor corresponding to Address, and it will drill down on it to extract the value of the Street property on it.

    A grid column of a BoundField derived type with DataField = “Address.Street” will work differently: it will just look for a property descriptor in the data item with a name as “Address.Street”. In fact, EntityDataSource is the first DataSource control that I know off that will provide such a thing.

    Bind(“Address.Street”) will work in a similar fashion to Eval() when reading the properties into the data bound control, but will act a little bit more like BoundField when sending back changes to the DataSource.

    There are a few cases in which the behavior is not any of the above and hence you end up with a control that cannot have access to a complex type’s properties. You can expect us to work closely with the ASP.NET team in making the experience smoother in future versions.

    Also, in this case, I think it is worthy of mentioning, you have to consider that flattening of properties in the EntityDataSource only happen under certain conditions. You can take a second look at the rules of wrapping (which is the mechanism we use to obtain flattened properties) in this blog post.

    Besides, we worked very closely with the ASP.NET Dynamic Data in this release, to enable their technology to work EDM through the EntityDataSource. I think it is very worthy of trying.

    Regarding what you see in the Windows Forms ComboBox, we don't do any flattening there, and so there is no property descriptor for "Address.Street". The way to get it is to do an explicit projection of "ContactId, Address.Street AS Street", and then bind the control to that. This will actually also work for you in any ASP.NET ListControl.

    Hope this helps,
    Diego