I have a hard coded html website of 5 pages and want to convert it to mvc4.
what do i need to do?
Is there a tutorial or step by step guide outlining how to make .html files dynamic via MVC?
You are going to want to get a basic understanding of MVC and especially the routing before you change it over - you will avoid a lot of confusion and pitfalls in the future.
Basically, all you will need to do is create Controllers (dummy, for now) for your html, and copy the html into the respective View. This will all make sense when you understand the routing in the global.asax file. Then I would update the links to #Html.ActionLink syntax and move from there - likely next extracting a _Layout for universal design, etc.
Basically, read a quick tutorial at minimum, or you will just frustrate yourself.
If the pages have unique data on them then you could create a controller for each page, a model and a view.
If all of the the pages have similar information you could have one controller with various views.
Related
I work on a big Active Directory Project where I need to remake the whole intranet application using ASP.NET MVC. I was wandering if Razor was a necessity here ? Especially for forms, I'm having a hard time with Razor forms (what a noob).
I have read that Razor is essential for scalable applications, which I guess is the case here, but if I could dodge this ugly stuff, that would be great.
In the end, do I need to use it for everything?
I have seen examples on the net that use classic HTML forms, and Razor for conditions and such. I don't mind using it for conditions, I just can't figure out how to render my forms with it. Is it ok to use normal html forms, or will it create some scalability issues in the future when I have 1 billion documents? :)
Thanks for your help, hope this isn't too redundant, I've seen this subject all over the place.
You don't need to use the Razor Html Helpers to generate form/input tags (you can use standard HTML markup), but you'll miss out on some of the benefits (specifically integration with a viewmodel to pre-populate fields, validation, etc). You'll also need to make sure your input names match up properly when capturing the FORM POST on the submission side.
It's up to you want you want to go with.
This can help you decide.View Engine Comparison
I need to port the functionality of this one and only one AJAX control to MVC, but given the poor selection of MVC controls out there, I think I need to bring this legacy control into the MVC world...
I'd rather not taint my MVC project with ASP.NET controls, and welcome json/MVC alternatives you know of. (post them if you know of any)
Sample UI that I need in ASP.NET MVC
Back to porting
Although it's unfortunate that I am left to porting this control to MVC, it seems to be a widely accepted practice since Telerik has detailed instructions on how do this.
That makes me ask:
How common is it for a MVC website to use ASP.NET controls?
Again I'll mention I don't want to do this so I welcome MVC-specific alternatives. That being said, I'll proceed with trying to merge that control with my existing site. </End Disclaimer>
If you click on this hyperlink, and look at the source code at the bottom, can you tell me where I should put the following in MVC?
Code behind (My first instinct is to use a Controller but another SO question indicates I should create a create a ViewName.aspx.cs file)
How do I port the SQLDataSource to the new "Model" way of thinking. I know they are different in nature but I don't know how to present data to a ASP.NET control in a way that it will consume the information.
How do I handle the AJAX component? This control has an AJAX component using callbacks. Yes this is getting ugly, but it seems like I have to do this.
Apparently this model saves data in session or view-state. I have no idea if this even work in MVC. Guidance, an alternate control, or a life preserver is much appreciated.
I've already done research and have instructions from Telerik here and here that describes how to get started with placing a simple menu, but I need a little assistance with the more complex controls like this one.
Note: For all the commentary that has hit this question, please remember that I only want this one ASP.NET control functionality; I can't find a comparable control in MVC.
porting from asp.net webforms to MVC is a paradigm shift.
Directly porting does not work.
The Model is where you typically describe your data and do the data access
the View is for displaying the data
The controller plums the other two together
So SQLDataSource is your data access layer and would therefore go to your model
the problem with the thought pattern of SQLDataSource == Model then you get away from the point of decoupling your presentation from data access
You have to think of MVC development as a new build
I would pick a book or video series from your preferred source and learn starting with MVC3 (it has some differences that simplify build speed and reinforce the difference between webforms and mvc)
Hope this helps.
This article explains how to run web forms and mvc together
http://weblogs.asp.net/rajbk/archive/2010/05/11/running-asp-net-webforms-and-asp-net-mvc-side-by-side.aspx
This is by telerik and explains the limitiation of the grid and what is need to get it to run.
http://blogs.telerik.com/aspnetmvcteam/posts/08-11-06/asp_net_ajax_controls_in_asp_net_mvc.aspx
Add an IFrame in your MVC view that just shows the WebForms page (or just use that control on a single WebForms page).
There is nothing that says you can't have a site with both WebForms and MVC pages. You can route a single URL to a WebForm just for this control.
Why not just use the telerik MVC controls? They work quite well. Either get them via a NuGet package or visit this link http://www.telerik.com/products/aspnet-mvc.aspx
I would rather use ViewModel instead of code behind
You don't have to throw away SqlDataSource you can use result set and buld from it your model, problem may be column names in result set... tricky but can be done
Since there is no components in MVC except helpers youll need help of jQuery probably, it easy
$.ajax({
url : "/controller/action",
data: { /*json or serialized form */ },
successs: function(data){
//if you got response as html from /controller/action
$("#some_div").html(data);
}
}
Session is available in MVC but viewstate not, you can use HttpContenxt.Cache or TempData if you need something like viewstate. USe TempData to keep data between redirections, or httpcontext.cache to cache your data further more.
I can't find similar functionality in an MVC control
MVC doesn't really have a concept of controls in the same way that ASP.Net does - there are only really the plain old HTML controls (i.e. hidden input, text input, checkbox, radiobuttons, select box, text area, password and buttons).
When you need something more complicated than the plain HTML Controls you need to use some JavaScript to achieve this.
I'm not sure that you will be able to 'port' the control into MVC - you will most likely have to try and re-create it your self using an MVC controller and a partial view with a fair bit of a javascript to create the control.
Have a look at the JQuery UI Autosomplete plugin - you could probably use this to acheive something similar
Is there a specific design practice for MVC type sites that need to have a lot of non-model related pages? I mean, it seems very silly to make a controller action for every single page; Yet at the same time, that seems to be the only way to realistically do it and adhere to standards. Is there any documentation or examples available for things like this?
When I speak of non-model pages, I mean things that are just display; Static information that you might use a standard HTML website layout for. But it has to be intermingled with other parts of the site that do require models and validation/etc.
Create a folder for your static content, and put in an ignore route for those pages. This causes those pages to be passed through directly to IIS for immediate display.
routes.IgnoreRoute("StaticPages/{*path}");
You can also load static HTML content into an existing View. This preserves your ability to work with dynamic content in the same page.
I don't think it sounds silly at all to make an action for every page. That's just how MVC works.
You can ignore some routes, as Robert Harvey suggests, but then you'll have the *.html extension on your static pages but not your internal ones, and you'll be unable to use the Url. and Html. helper methods for linking to MVC actions.
I think you should just go with the flow.
Another alternative was suggested for common static files such as help pages which is based more on a naming convention, but would allow for some flexibility in layout control in the view:
ASP.Net MVC Routing Strategy for Static Content
We have a fairly complex application that was previously using WebForms. We are in the process of rewriting bits of it from scratch using MVC. Our application is comprised of a number of widgets, that together make up the functionality of the application.
In WebForms, we used UserControls. Each UserControl would register its CSS and JavaScript by means of a collection that was stored in HttpContext.Current.Items. That collection would then be merged to output as one single request. Typically this would occur in the Page_Load event, and the containing page would then render out a script tag that would comprise all the JavaScript and CSS needed for that page.
We've been struggling with doing the same in MVC. We are using a number of views within a masterpage to mimic the widgets. Each widget has its own controller, so the functionality can be sufficiently segregated. The masterpage builds up the widgets on the page using RenderAction from MVC futures. Originally we were using the same registration method for the CSS/JS files. Each controller would register its required files in an Action. The files would then be contained in the HttpContext.Current.Items collection, and would be rendered out to the page. To facilitate this, I wrote an HtmlHelper extension to render the links/scripts out to the page. It looks like this:
<%= Html.GetRegisteredCssFiles() %>
The problem is that MVC uses a more top down approach. This call is made in the tag of the page, but our subsequent calls to RenderAction happen below. By the time RenderAction is called and the required files are registered in HttpContext.Current.Items, the code above has already executed. So, the collection is not modified at the right time.
Does anyone have any ideas on how we should be constructing this? I'm looking for answers that incorporate best practices for MVC.
This question was asked a lot of time ago, so probably you've dealt with this already. But for future visitors, maybe this solution will be helpful:
http://marcinbudny.blogspot.com/2010/01/handling-stylesheet-references-in.html
The Free Telerik MVC tools have a script and a style register that might do what you want ...
Not sure if this is a feasible solution for you, but try moving that call to the bottom of each page.
I've always included my javascript and css files in the html HEAD, so I don't know if it would work lower down. My assumption is that it'll work in most browsers, but you might have random problems in a few.
The alternative is to have GetRegisteredFiles() output some javascript that loads the CSS files in the proper place (via DOM manipulation).
The problem with either of these solutions is that the files aren't included until the end, which could cause the page to look "plain" until the CSS is downloaded.
Alternatively, the controller could predict which "widgets" will get loaded and pass that data to the master page.
I have an application that will support multiple sites. The site will be determined based on the url.
For example
http://myapp/site/abc123/...
and
http://myapp/site/xyz123/...
The site code will drive a lot of the functionality for example themes, available modules, etc...
Questions:
1-)I need to validate the site code is valid and if it isn't, it should direct the user to an info page. I was looking at using IRouteConstraint, is this appropriate? Are there other/better options?
2-)Any gotchas with this approach (using url to identify site)? Is there are better approach?
Solution
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.
The system I have implemented uses Urls to identify unique page content within a single site and the routing process is pretty straightforward. That being said, you may want to consider making use of Areas in your MVC application. With Areas you can have multiple sections to your website that all have their own MVC structure which can run semi-independently.
Essentially, you will have one base routing definition that lays out some defaults and then the rest of the "sites" will define their own routes pointing to controllers and views in a separate location. It's pretty easy to set up, you'll just need to make sure you're using version 2.0 of ASP.NET MVC. Here's a decent looking tutorial on ASP.NET MVC Areas and Routes. In the current model which MVC 2.0 supports you'll have a single Web project for each area, but that is not necessarily a requirement. Phil Haacked has some code for ASP.NET MVC Single Project Areas if you're looking for another example of the technique, although you, personally, will probably benefit more from the first article.
So long as you define good routes that have clear and measurable constraints, you shouldn't have too much trouble laying out the website you've described.
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.