Last post Jan 31, 2008 03:45 PM by MikeBosch
Jan 31, 2008 12:48 PM|jason_m|LINK
I have 2 questions (totally unrelated) about the mvc framework. I've only read about it. I haven't installed any of the requirements to use mvc (vs08, mvc bits/ext.)
I believe my questions stem from the fact that I rely very heavly on asp.net and no very little about REST, html, js. There's always something new to learn:)
Jan 31, 2008 02:17 PM|tgmdbm|LINK
1) I was going to say you could do this with the MVCContribs ConventionController. Simply inherit from ConventionController and apply the Deserialise attribute to your argument. like:
public void SomeAction(string text, [Deserialise("prefix")] List<int> selectedValues)
but then i looked at it and you can't. that expects array and list types to be in prefix. prefix format but this is just a single field passing back a comma separated list of ints. If they're listening maybe they'll fix it so this works?!?
the easieast way to do this is just SomeAction(string, string) and split the selectedValues by comma.
2) this doesn't require any special markup, the only thing you need to think about is the naming of the form elements.
3) don't be afraid of runat=server. There's probably going to be a calendar control in the suite of controls that come with the MVC Framework when it ships. you can actually currently use the old asp.net controls on your forms, but because you've lost postback
they're only good for rendering html (which they typically don't do very well imho)
Jan 31, 2008 02:25 PM|jason_m|LINK
I agree the markup for server controls is limited at best.
so I could create a form tag without the runat attribute and still use <asp:TextBox runat="server" id="foo" /> ? This I did not know. Comes back to my limited knowledge of html. Using server controls still renders the ulgy ClientID correct?
Jan 31, 2008 02:35 PM|tgmdbm|LINK
yes, there are a lot of classic controls that don't need a <form runat="server">
and, no, because you're not using webforms you don't get any of that ctrl12$... rubbish, just the plain old ClientId == Id semantics
you don't have postback, so none of the events of the texbox fire, and you can't reference the Textbox in the controller to do Textbox1.Text or anything like that. they are purely for rendering html.
Jan 31, 2008 02:44 PM|jason_m|LINK
thanks for the information. this will be helpful when converting to mvc.
Jan 31, 2008 02:50 PM|Fredrik N|LINK
The Web Server Controls will genereate a unique Id, the rendering process of the Contorls aren't changed. You can also add them into a <form runat="server"> and access them from the code-behind of the View and set some values even if I shouldn't do that.
The TextBox control need to be inside of the <form runat="server">, so some of the original controls need the form tag.
Microsoft will add new controls that will work with the MVC framework, or at least looking at it. We have some sort of helper methods today to create elements.. for example the HtmlHelper class, which has several of extenstion methods added if the MVcToolkit
will be used.
As tgmdbm mention, the Postback will not work correclty. some controls will still do a postback, but the idea is not to use postback.. for example the ViewState will not work correctly etc. The whole thing with the MVC Framework is to use the MVC Pattern
instead of a Web Form postback solution. So no event driven pogramming etc. The Controller has "action" methods that should be called instead and perform some action based on user input etc.
Jan 31, 2008 03:06 PM|tgmdbm|LINK
Oops, he's right, i remember ScottGu saying there is a way to turn it off tho. but a quick search hasn't revealed anything.
if you need to you can always use <input runat="server">
Jan 31, 2008 03:10 PM|tgmdbm|LINK
One approach would be to use ASP.NET's HTML intrinsic controls instead of the <asp:> ones for things like buttons and checkboxes. These are easy to use - just add the regular HTML elements to the user control and then add an "ID" attribute and a runat="server".
These won't complain about needing to be in a <form> element.
If you want to use a control that needs to be in a <form> element to render, one approach you could take would be to dynamically inject a form element under the page class (within the RenderView method I built, and then add the UserControl under that). You
could build your own custom derived page class that stripped out the <form> control's rendering output if you wanted - which would then cause you to only return the exact HTML that you need.
Hope this helps,
Jan 31, 2008 03:20 PM|jason_m|LINK
To sum up:
Jan 31, 2008 03:45 PM|MikeBosch|LINK
<div>What are devleopers using for calendar controls?</div>
I would recommend looking into some client side calendars. I typically use jQuery for these UI elements: