Recommendations

[Dennis]

In order to have models such as this...

public class ExampleViewModel : ViewModel
{
public string[] Field1 { get; set; }
public string Field2{ get; set; }
....
}

The AggregateDictionary needs to be modified as follows:

public AggregateDictionary(HttpRequestBase request, RouteData
routeData)
{
AddLocator(key => request.Params.GetValues(key));
....

This will facilitate the ability for a model property to be properly
mapped. For example, given the following QueryString,Form variables,
Server variables etc (see the Request.Params documentation):

Field1=123&Field1=456&Field2=test

We can now consider mapping "Field1" as a string array. In the
DictionaryConverter.Populate method, the following could be applied:

if (propInfo.PropertyType.IsArray)
{
if (propInfo.PropertyType == typeof(string[]))
{
propInfo.SetValue(item, values
[propInfo.Name], null);
}
.....

As a result of these minor changes, I can now use jQuery like this:

var f = $("#exampleForm");
$.post(f.attr("action"), f.serialize());

for this form:

<form action="..." method="post" id="exampleForm">
<select id="Field1" name="Field1" multiple="true" >
<option value="123">Example 1</opton>
<option value="456">Example 2</opton>
</select>
<input type="text" id="Field2" name="Field2" />
<input type="submit" value="Send" />
</form>

The above simply async POST's the form with the Content-Type:
application/x-www-form-urlencoded specified and the HTTP body set to
this:

Field1=123&Field1=456&Field2=test

I'm currently using this approach successfully.

Hope this helps
Dennis

[Nick]

Agreed. We ran into this as well because some of the input had commas,
so the comma-separated string that was coming back would not work.

Another similar issue I've run into deals with render partials. For
example, if we have:

public class SomeInputViewModel : ViewModel
{
public string MemberOne { get; set; }
public string MemberTwo { get; set; }

public SomeDisplayModel { get; set; }
}

public class SomeDisplayModel
{
public string DisplayModelMember { get; set; }
}

we have two options for using with a form. The first is doing
something like

<%= this.RenderPartial().Using<SomeUserControl>().For(c =>
c.SomeDisplayModel.DisplayModelMemeber) %>

which give the form element a name of
"SomeDisplayModelDisplayModelMember". However, when this comes back
from the form, Fubu doesn't know where this goes since
SomeInputViewModel does not have a member with that name.

The second option is to create a separate user control that takes
SomeDisplayModel. However, whenever this gets output, the form element
has name="DisplayModelMember", and then we have the same problem of
not being able to map DisplayModelMember to SomeInputViewModel since
that property doesn't exist either.

That leaves the only real option to be using only primitives for
ViewModels that expect input, but this either creates a lot of
duplicate code or more levels of inheritance.

In my mind, FubuMVC should output names for objects like
name="SomeDisplayModel[DisplayModelMember]". Then we would be able to
map input back to actual objects.

What do you guys think?

[Nicholas Lindley]

I just realized I didn't give SomeDisplayModel a variable name. Looks
like it should also be called SomeDisplayModel from my usage. Also,
the syntax I suggested could be used to nest even deeper. For
example, ?object[objectMember][objectMemberMember]=value.

[Dennis]

I would discourage this style of variable names. I think vairable
names should match 1 to 1 to a model property. For properties that
return child models (a model with a defined hierarchy), a completely
different deserialization should be applied to the request. JSON and
XML are better structures for handling these types of complexities.

In my estimation, trying to "munge" state from a dictionary
(Request.Params, Form etc) to a hierarchial model is problamatic.
Either flatten the model or rely on a completely different means to
deserialize(hydrate) the model.

I have never liked ASP.NET naming convention .. ie
ctl100_myform_myfield... for simple view models, MyField1 & MyField2
seems less complicated. For hierarchial view models, relying on the
HTTP Request Body which contains JSON/XML to deserialize the display
model seems cleaner to me.

> >> Dennis- Hide quoted text -
>
> - Show quoted text -

[Nick]

However, relying on XML or JSON models also requires relying on
JavaScript to pass back any structure from the client. In my opinion,
JavaScript is not a concern of FubuMVC. For rapid development, a
programmer should be able to define the form and get data back into
that definition without having to jump through serialization/
deserialization hoops.

Maybe I have just spent too much time looking at things like PHP and
RoR, but regardless of any of their design flaws, they were built with
the web in mind and handle structure in much the same way. My main
problem is that I can't reuse ViewModels or DisplayModels for form
submissions without depending on inheritance. Also, when you get into
things like JSON and XML HTML encoding/decoding becomes a little more
interesting.