Binding ASP.NET MVC form submissions to LightSpeed Entities

Hi,

I'm trying to bind incoming form data to a LightSpeed entity. Using the ASP.NET MVC binding code works well for simple objects but I can't get it to work for more complex situations so I have two questions:

1) Is it necessary to use the EntityModelBinder class or is the DefaultModelBinder that comes with MVC a feasible option with LightSpeed?

2) How do I structure my web form fields so that a more complex object is correctly bound? (and will this work with LightSpeed's EntityModelBinder class and/or the DefaultModelBinder class?)

I am trying to populate the following class structure from a single form submission (WarehouseItem inherits from Entity):

and my current attempt at a HTML form to create a new Species with an LSID string and two SpeciesName objects (with new Language objects) is:

<input id="LSID" name="LSID" type="text" value="defaultLSID" />
<input id="PrimarySpeciesNames[0]_Value" name="PrimarySpeciesNames[0].Value" type="text" value="" />
<input id="PrimarySpeciesNames[0]_Language_IETF" name="PrimarySpeciesNames[0].Language.IETF" type="hidden" value="la" />
<input id="PrimarySpeciesNames[1]_Value" name="PrimarySpeciesNames[1].Value" type="text" value="" />
<input id="PrimarySpeciesNames[1]_Language_IETF" name="PrimarySpeciesNames[1].Language.IETF" type="hidden" value="en" />

NB: This is isn't how we will populate these classes in the final version of our application but it is a simple example of the sort of data binding that we will need to do with a number of more complex Entities soon.

Can anyone answer either of my questions or point me to any potentially useful information?

Thanks,

Chris

Hi Chris :)

The EntityModelBinder will more accurately bind to LightSpeed entities as it leverages the internal model which LightSpeed uses for managing the fields on the entity where as the DefaultModelBinder just blindly maps, however AFAIK neither extend to walking relationships. Please correct if that assumption is wrong on the DefaultModelBinder front.

Generally the approach we would recommend is to unbind an entity and also have an Id which you might optionally use to load in an existing entity. This is something you could also have automated inside the model binder, but I generally prefer more manual control around this to avoid potential security issues (e.g. I supply an artitrary Id and away we go..). If you are always creating new entities then you wont need an Id property on the form of course :)

In terms of unbinding down relationships, this is not something we have looked at. But it would certainly be achievable with some customisation within the model binder (most things are).

Another way of achieving this (assuming you have the fixed number of objects as per your form) would simply be to accept two SpeciesName objects as part of your request and then simply call .Add() to the SpeciesNames collection.

 

Jeremy

 Hi Jeremy,

Thanks for the reply, I think I am starting to understand the issues a bit more clearly although I have a little way to go! I'm a bit confused by the difference between "unbinding down relationships" and "walking relationships" during a data binding operation.

I was unsure whether the DefaultModelBinder could follow relationships but have done some more research. Maybe it is naive but I am considering "walking relationships" to be the same issue as traversing a deep object graph (please correct me if this is not accurate with regard to LightSpeed's internal model).

In that respect I think that this forum post contains information which suggests that this method of binding is supported in the DefaultModelBinder: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework.aspnet&tid=773ab148-9814-4f45-96d0-5997283e38e4&cat=en-us-msdn&lang=en&cr=US&sloc=en-us&m=1&p=1. The last post (5/21/2009 8:35 PM PST) has a fairly simple example of binding form data to a property on a deep object within a collection and there are more complete code examples earlier in the thread which demonstrate binding against even deeper object graphs.

I'm not really sure where to begin in assessing whether this can be implemented with LightSpeed and how much work would be involved but since you seem to be the resident LightSpeed MVC expert I wonder if you can see any way that this functionality could be added to the EntityModelBinder?

I think an automatic binding of any LightSpeed object submitted from a view is the neatest way to go but your recommended approach with an Id may provide a workaround, as might the suggestion of accepting two SpeciesName objects as part of the request. I'm not sure how this would work in practice though. I tried creating a separate View Model which contains LightSpeed Entities but had trouble getting that to work (and I think that it would have been trying to use the DefaultModelBinder anyway which defeats the point of neat integration with LightSpeed)*.

Where were you imagining the optional Id to reside? It could be a property on the Entity I suppose but I don't like the idea of cluttering up the application's data model just for the purpose of enabling data binding on a website (potentially only one of many uses of our LightSpeed data model).

Just to be clear, I am trying to achieve all of this with strongly typed view models rather than a dictionary of text strings. I can't see a way to associate more than one model with a view but this may just be due to my lack of ASP.NET MVC knowledge.

Thanks again for your help with this,

Chris

 

* Here's the View Model I  was working with (although it's not that great becuase it means we have to assume specific languages):

public class SpeciesViewModel
    {
        public Species Species { get; set; }
        public SpeciesName PrimaryCommonName { get; set; } // implicitly English language
        public SpeciesName PrimaryScientificName { get; set; } // implicitly Latin language
    }

 

Hi Chris :)

Yep, my interpretation of that article seems to indicate that its unbinding arrays via reflection as well. The EntityModelBinder doesnt do this as it just walks the internal value model for the entity you are unbinding. Rather than adding this to EntityModelBinder as default behavior, I think we could look at adding it as an optional behavior. We would probably want to support both new objects and finding existing objects in a collection via some nominated key.

The use of an Id field for indicating which object to load from the repository is more of a safe guard, because if you have to do this manually in your controller code then you also have the opportunity to wrap some guards around the operation :) Again, its possibly something which would be sensible enough to add in as an option to the EntityModelBinder as you can make an informed choice on the matter..

 

Jeremy

 Hi Jeremy,

Thanks for looking at that article, it's reassuring to know I'm not completely misunderstanding MVC data binding. That said, I'm still not clear how one could pass options to the binder.

The examples I've found so far simply supply one single LightSpeed Entity to each controller action. E.g.:
public ActionResult New(Film film) { ... }

How would that be extended to support extra options such as id fields or a request to walk related objects?

The idea of supporting new objects and a key to find existing objects sounds good (although as before, I can't visualise how this key can be passed from the view to the model binder or controller while using a view which is strongly typed to a LightSpeed Entity).

I appreciate that this model binding is not a core part of the ORM (although it does seem essential to make LightSpeed integrate properly with ASP.NET MVC websites) so I understand if this is not your highest priority task but I will need to find a way to bind incoming data to a model at some point soon so I was wondering if you think you may be able to implement any of these modifications in the near future? Maybe in the next week or two?

I could take a stab at the implementation myself but I suspect it will take me a very long time and be far from perfect owing to my lack of knowledge regarding both the internal working of MVC model binders and the LightSpeed internal model. So with that in mind I would be eternally grateful if you are able to devote some of your time to extending the EntityModelBinder so that it can support unbinding arrays and relationships to other Entities.

Many thanks,
Chris :-)