I have a few suggestions for the MVC team, as explained in greater depth in a blog post here: http://www.mertner.com/morten/?p=29
Quick summary:
1) Allow omitting the Controller part of the controller class name for the Html helper class methods (ActionLink, Form, etc.).
2) Provide a mechanism for strongly typed data binding. The blog post above has a sample showing how even a simple ActionLink ends up being really ugly.
I hope this is the right place to post suggestions such as these.
I strongly agree with the strongly typed databinding suggestion. Right now, databinding is a weak link in the compile time application validation. I would like to see this with the regular Asp.net databinding, too.
You need the Controller name to be referencing the correct type. With typed ViewData binding is very clean to write, and simple within the controller with UpdateFrom. You could of course create your own custom Extension Methods for
in the View, if you need a special type of SafeGet type of access to a property.
I am binding to a list of elements using the Repeater control, so it is not possible to use type safe binding to a property - and this is the case regardless of whether the viewdata is typed or dictionary-based. I should have made this clear in the blog
post.
And I really despise having to litter my markup with code to iterate some collection. The syntax for databinding a collection of items should be just as clear and typesafe as the example you provided, but unfortunately isn't.
Binding.UpdateFrom is also an unfortunate solution because there is no easy way to add hooks for validating the submitted data, and rarely do I have a form where this is not needed.
And I really despise having to litter my markup with code to iterate some collection.
Despise is such a strong word.
Watch Scott presentation at MIX, http://www.hanselman.com/blog/ASPNETMVCSessionAtMix08TDDAndMvcMockHelpers.aspx
2 obvious solutions come to mind, 1) use foreach and all the lovely syntax, strong typing and intellisense that comes with it, or 2) write an extension method on DataItem to simplify your code.
If the best solution is to put lots of code blocks for iterations and switches into my markup, explain to me why I shouldn't switch to a more proven platform (PHP for instance) for doing exactly this. One of the advantages of .NET has been better separation
between markup and code. The more logic that creeps into markup, the harder it becomes to work in tandem with web designers who have no clue what all the <% %> blocks are for.
Using extension methods is neat - I'll head down that road, thanks. I still think the syntax is much too verbose and could be simplified, even though it's a major step in the right direction.
I think you don't give designers enough credit. At least "for each product in view data dot products" reads as (almost) english.
And anyway, the view is chock full of logic. A Repeater embodies a for loop, it's just hidden inside a control. The point is that it is the "logic" of how to display the html.
I'm not going to justify to you why you should use mvc.net, and frankly, if you need convincing you should think hard about using it. Go with what you're most comfortable with, if that's PHP, rock on. It's purely your choice.
But the whole point is that the view shouldn't have any logic. That's why it's a view and not a controller.
What makes the repeater nice for displaying collections is that it encapsulates not just iteration and plain display of items but also has logic to display header, footer and alternating templates. Using <% %> blocks to achieve the same thing is much more
verbose and above all ugly.
I'm not a PHP developer and have no intention of switching to it. I was using it to illustrate a point: Taking MVC to where PHP has been for 5 years is 2 steps backwards rather than 1 step forward. If you've ever seen a large PHP project you'll see why mixing
code blocks with markup is a really bad idea.
MVC cleanly separates concerns and allows for easy testing, and these are great benefits. I just think the rendering and data binding experience (aka view part) is lacking.
The whole point is that the view should not contain any Application or Business Logic.
Presentation logic most certainly lives in the view or a view helper, and the designers should have full control of how they want to present presents things.
I agree that this is messy and we need a way to allow Designers to access controller data in a clean and simple way. but I am afraid that HTML doesn't do Logic, and there must be some logic in views, therefore designers will have to be able to code...
Agreed, it will not be possible to have views without any logic. But it should be the lofty goal to require as little logic as possible in the presentation layer, and encapsulations like the repeater control in unison with data binding is a great example
of how the amount of apparent logic can be reduced.
Saying that designers will have to be able to code is counter-productive, as it essentially implies defeat. The less that they need to know, the easier it will be to train and work with them, and keeping this in mind is important if you want to convince non-developers
to use MVC.
That said, the original topic somehow side-tracked into this discussion. My original point was that the existing syntax for data binding was quite verbose and cumbersome. It'd be great to see enhancements in this area, like the suggested set of extension
methods or automatic anonymous type provisioning.
mnmr
Member
7 Points
11 Posts
MVC Preview 2 Suggestions
Mar 08, 2008 02:52 PM|LINK
I have a few suggestions for the MVC team, as explained in greater depth in a blog post here: http://www.mertner.com/morten/?p=29
Quick summary:
1) Allow omitting the Controller part of the controller class name for the Html helper class methods (ActionLink, Form, etc.).
2) Provide a mechanism for strongly typed data binding. The blog post above has a sample showing how even a simple ActionLink ends up being really ugly.
I hope this is the right place to post suggestions such as these.
willc
Member
174 Points
38 Posts
Re: MVC Preview 2 Suggestions
Mar 08, 2008 04:15 PM|LINK
I strongly agree with the strongly typed databinding suggestion. Right now, databinding is a weak link in the compile time application validation. I would like to see this with the regular Asp.net databinding, too.
andyfreestyl...
Member
171 Points
56 Posts
Re: MVC Preview 2 Suggestions
Mar 08, 2008 05:20 PM|LINK
I'm confused about your comments and syntax - see my modified versions below.
Using ViewPage<Media>
<%= Html.ActionLink<MediaController>( c => c.Show(ViewData.ID), ViewData.DisplayName) %>
<%= Html.TextBox("Media.DisplayName", ViewData.DisplayName) %>
Within Action
Binding.UpdateFrom(instance, Request.Form);
You need the Controller name to be referencing the correct type. With typed ViewData binding is very clean to write, and simple within the controller with UpdateFrom. You could of course create your own custom Extension Methods for in the View, if you need a special type of SafeGet type of access to a property.mnmr
Member
7 Points
11 Posts
Re: MVC Preview 2 Suggestions
Mar 08, 2008 09:51 PM|LINK
I am binding to a list of elements using the Repeater control, so it is not possible to use type safe binding to a property - and this is the case regardless of whether the viewdata is typed or dictionary-based. I should have made this clear in the blog post.
And I really despise having to litter my markup with code to iterate some collection. The syntax for databinding a collection of items should be just as clear and typesafe as the example you provided, but unfortunately isn't.
Binding.UpdateFrom is also an unfortunate solution because there is no easy way to add hooks for validating the submitted data, and rarely do I have a form where this is not needed.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: MVC Preview 2 Suggestions
Mar 08, 2008 10:30 PM|LINK
Despise is such a strong word.
Watch Scott presentation at MIX, http://www.hanselman.com/blog/ASPNETMVCSessionAtMix08TDDAndMvcMockHelpers.aspx
2 obvious solutions come to mind, 1) use foreach and all the lovely syntax, strong typing and intellisense that comes with it, or 2) write an extension method on DataItem to simplify your code.
e.g.
<%# Html.ActionLink<MediaController>( c => c.Music( Container.DataItem.Get<int>( "ID" ), Container.DataItem.Get<string>( "DisplayName" ) ) %>Something like that but you get the idea,
mnmr
Member
7 Points
11 Posts
Re: MVC Preview 2 Suggestions
Mar 08, 2008 11:13 PM|LINK
If the best solution is to put lots of code blocks for iterations and switches into my markup, explain to me why I shouldn't switch to a more proven platform (PHP for instance) for doing exactly this. One of the advantages of .NET has been better separation between markup and code. The more logic that creeps into markup, the harder it becomes to work in tandem with web designers who have no clue what all the <% %> blocks are for.
Using extension methods is neat - I'll head down that road, thanks. I still think the syntax is much too verbose and could be simplified, even though it's a major step in the right direction.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: MVC Preview 2 Suggestions
Mar 08, 2008 11:53 PM|LINK
I think you don't give designers enough credit. At least "for each product in view data dot products" reads as (almost) english.
And anyway, the view is chock full of logic. A Repeater embodies a for loop, it's just hidden inside a control. The point is that it is the "logic" of how to display the html.
I'm not going to justify to you why you should use mvc.net, and frankly, if you need convincing you should think hard about using it. Go with what you're most comfortable with, if that's PHP, rock on. It's purely your choice.
embrace the <% %> !!
mnmr
Member
7 Points
11 Posts
Re: MVC Preview 2 Suggestions
Mar 09, 2008 12:27 AM|LINK
But the whole point is that the view shouldn't have any logic. That's why it's a view and not a controller.
What makes the repeater nice for displaying collections is that it encapsulates not just iteration and plain display of items but also has logic to display header, footer and alternating templates. Using <% %> blocks to achieve the same thing is much more verbose and above all ugly.
I'm not a PHP developer and have no intention of switching to it. I was using it to illustrate a point: Taking MVC to where PHP has been for 5 years is 2 steps backwards rather than 1 step forward. If you've ever seen a large PHP project you'll see why mixing code blocks with markup is a really bad idea.
MVC cleanly separates concerns and allows for easy testing, and these are great benefits. I just think the rendering and data binding experience (aka view part) is lacking.
Phil Zmith
Member
2 Points
1 Post
Re: MVC Preview 2 Suggestions
Mar 09, 2008 12:42 PM|LINK
The whole point is that the view should not contain any Application or Business Logic.
Presentation logic most certainly lives in the view or a view helper, and the designers should have full control of how they want to present presents things.
I agree that this is messy and we need a way to allow Designers to access controller data in a clean and simple way. but I am afraid that HTML doesn't do Logic, and there must be some logic in views, therefore designers will have to be able to code...
mnmr
Member
7 Points
11 Posts
Re: MVC Preview 2 Suggestions
Mar 09, 2008 01:03 PM|LINK
Agreed, it will not be possible to have views without any logic. But it should be the lofty goal to require as little logic as possible in the presentation layer, and encapsulations like the repeater control in unison with data binding is a great example of how the amount of apparent logic can be reduced.
Saying that designers will have to be able to code is counter-productive, as it essentially implies defeat. The less that they need to know, the easier it will be to train and work with them, and keeping this in mind is important if you want to convince non-developers to use MVC.
That said, the original topic somehow side-tracked into this discussion. My original point was that the existing syntax for data binding was quite verbose and cumbersome. It'd be great to see enhancements in this area, like the suggested set of extension methods or automatic anonymous type provisioning.