Gizmo (1) [Avatar] Offline
I see a big difference in the way form post methods are handled between your latest MEAP drop and the examples I've seen from Scott Guthrie. I'm trying to figure out the best way to go and would like to start a discussion about the pros/cons of each. Here's what I see so far:

Scott's Method:

GET version of Create method displays data entry view -> data is posted to PUT version of Create method -> model binder binds to object -> binder puts validation errors into ModelState -> if errors not present, save and redirect -> if errors are present, re-display data entry view (without redirect) allowing user to re-enter values and repost.

Pros: Don't need validation step in the GET version of Create method.
Don't need to send data in QueryString to GET version of Create method.
ModelBinder is solely responsible for data validation.

Cons: User could hit "refresh" on the screen showing validation errors. Not a big deal in most cases as they'll just get the same screen back, but prevents "partial entry" scenarios where valid data is stored before showing invalid data (such as with list input).
Data validation gets sort of "hidden" within binders instead of within display objects where it probably belongs.

Book Method:

Create method displays data entry view -> data entry view calls object Validate method to populate ModelState -> if invalid, errors will be displayed in entry view -> data is posted to New method -> model binder binds data to object -> object Validate method populates ModelState -> if valid, redirect -> if not valid, redirect back to Create with data in QueryString.

Pros: No "refresh" issues.
Object holds its own validation logic.

Cons: Need to pollute querystring with data.
Need extra validation in Create method.
Forms with large amounts of data can blow-out querystring.

So, as I see it, the big con with Scott's method is that partial updates could cause data duplication. Example: User enters list of Part IDs to add them to a Part Order (quicker than "click to add" for users that have part id logic stuck in their heads...) Two of three part IDs were good, so add them to Order, but one was bad, so redisplay entry form (which also shows Order) which now contains two parts and shows the error on the third. If the user hits "refresh" now, the first two parts are added again (or their quantities increased by one - however the logic works).

The big con with the Book method is the whole querystring issue. For one, what about clients that really want a huge amount of data entered in a form (usability aside - client wants it, client gets it...) - querystring has a limit! Plus, it's just plain ugly to shove that stuff in querystring and now we're at a page the user might mistakenly bookmark and get crap when they come back...

So, what do you guys think? Given those issues, where would you go with it? Is the "Book Method" being changed now that Beta is release anyway?
ben.scheirman (54) [Avatar] Offline
Re: Form Post Scenarios
A lot is on the plate to be changed, and with the RC literally around the corner, we'll be making revisions of these older chapters to reflect the changes.

I agree with you though that there are pros/cons of either method, and we'll revisit this when it comes time to revise that chapter.

Thanks for the detailed input! It is really appreciated.
James Fleming (2) [Avatar] Offline
Re: Form Post Scenarios
It's nearly December - so where's the revisit? smilie