Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Mar 09, 2008 01:03 PM by mnmr
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
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.
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.
Mar 08, 2008 05:20 PM|LINK
I'm confused about your comments and syntax - see my modified versions below.
<%= Html.ActionLink<MediaController>( c => c.Show(ViewData.ID), ViewData.DisplayName) %>
<%= Html.TextBox("Media.DisplayName", ViewData.DisplayName) %>
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
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.
Mar 08, 2008 10:30 PM|LINK
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.
c => c.Music(
Container.DataItem.Get<int>( "ID" ),
Container.DataItem.Get<string>( "DisplayName" )
Something like that but you get the idea,
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.
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 <% %> !!
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.
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...
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.