I'm passing a list of controls into the view (e.g. information such as - the Id of the control, the type of control, whether it's a required field etc) and am then going to build them up either via the view or through jQuery...but i was wondering whether it would be vastly more efficient if the html controls were build up from jQuery?
Cheers.
but i was wondering whether it would be vastly more efficient if the
html controls were build up from jQuery?
No, it would be vastly more efficient to use an ASP.NET MVC view and have those controls built on the server using the view model that is passed from the controller to the view.
If you want to dynamically add/remove controls later on the client then yeah, jQuery would be a great choice.
Related
I want to create a view that can be used twice on the same page, each time with a unique id.
At the moment I'm using two approaches to do this kind of thing
Editor Templates
stevensanderson's approach for having controls created on the fly
Editor Templates are the easiest as they take of the name mangling (e.g. parent1_parent2_childId) but Editor Templates can't be used across Areas and I really like Areas
Is there a 3rd option?
thanks
You can pass a model to a child view in the RenderPartial extension method. Use this mode to pass a desired id, or something from which it can be obtained.
I'm developing a big, ritch (lots of client-side js code) website and I'm thinking about standing out a set of reusable controls. And here comes the question: what is the best way to design these controls in MVC?
Yes, I know - there are partial views. But from my point of view this is not enough. What I want is first-class building blocks that I can reuse in my application.
Say I have a control that consists of customer data:
name
surname
email
phone
Of course I can develop a partial view and reuse it, but I need also other elements:
model
validation
server side call that retrieves / changes the model (proper WCF calls to some application server)
presentation logic (same control should be able to render as static text and also a form that allows data change)
These elements should be encaplsulated in one place (a control - component - assembly).
Is my way of thinking reasonable or there are better design patterns in MVC?
m.
Editor and Display templates is a good practice http://blogs.msdn.com/b/nunos/archive/2010/02/08/quick-tips-about-asp-net-mvc-editor-templates.aspx
I don't want to make this into a "which is better... MVC or WebForms" type of question. Im sure that has been asked a bunch of times here already.
My Question: If I am building a MVC web project, why should I not use an ASP.NET datagrid control on one of my "Views" .aspx pages?
The control relies on Viewstate which isn't available in MVC. In addition, all the behavior is predicated on the WebForms event and postback model which you'd have to recreate in MVC to get them to work. You could search for alternate, MVC-friendly grids (perhaps jQuery-based). I know that Telerik has released a set of MVC controls under open source that might be helpful to you.
you can't use web forms controls in MVC because they depend on view state. Use the data grid of the Mvc Controls toolkit instead. It has paging, insert delete and update capabilities and it is completely templated (you can shap it as you like). Look at it here
The datagrid control depends on postback events which does not fit into the MVC way of thinking (the postback goes to the page code behind rather than the controller). You could use one without any postback features, i believe, but you may as well craft something directly.
Because the ASP.NET DataGrid / GridView has too much responsibility to fit into the MVC pattern. You'll have to add some code-behind to your view to databind the grid - code that belongs in the controller.
Anything that uses postback won't work with MVC, so the DataGrids paging and sorting won't be any good to you. So there really isn't any benefit to using it.
If you're looking for a flexible grid 'control' (MVC prefers the term HTML Helper), the MvcContrib grid is pretty good.
Is there a new model or best-practise for creating complex controls in asp.net MVC?
Do you use code-behind or inline to mirror your view pages?
My model is this:
I tend to use Partial Views when there is a view element that I'll need to use more than once. Or if I need to display multiple complex object in a view.
I use RenderAction from the futures assembly when I need a "reusable widget" of sorts. It has it's own controller and is better at handling more complex logic than a Partial View.
Finally, I tend to write Html Helper methods for things I may use in other projects (like paging links, etc).
I would use a partial view for complex things. Check out this article
Controls in MVC don't generally have (any) code behind. You use PartialViews as ascx controls, you pass them a model and you display the contents of the model.
You can create custom controls in mvc and these compile to a dll which is moveable between projects etc and these are a little more complex but essentially they spit out html like the partial view does.
You can also create jQuery plugins that are pretty cool and again, they can spit out html based on a model.
So a typical mvc view may be comprised of several partial views each of which are dedicated to a model or hierarchy of models.
Partial views can also display partial views so you can send a complex model to a partial view which in turn renders other partial views each of which deal with a more atomic part of your model.
I've been writing a lot of my own HtmlHelper extension functions. The November meeting of http://www.c4mvc.net/ that was recorded today gives some great examples of control type code placed in HtmlHelper extension functions. The recording should be online soon.
You may also want to check out the Telerik Extensions for ASP.NET MVC. They're open source, so even if you don't use their controls, you can get some insight into controls in ASP.NET MVC by taking a look at how a commercial control vendor approached the problem.
Coming from a PHP turned webforms turned ASP.NET MVC background, I find myself relying a lot more on basic html/css/javascript.
I've never been a fan of controls, even with webforms because they always ended up being messy compared to js/html/css counterparts.
What is the 'page lifecycle' of an ASP.NET MVC page, compared to ASP.NET WebForms?
I'm tryin to better understand this 'simple' question in order to determine whether or not existing pages I have in a (very) simple site can be easily converted from ASP.NET WebForms.
Either a 'conversion' of the process below, or an alternative lifecycle would be what I'm looking for.
What I'm currently doing:
(yes i know that anyone capable of answering my question already knows all this -- i'm just tryin to get a comparison of the 'lifecycle' so i thought i'd start by filling in what we already all know)
Rendering the page:
I have a master page which contains my basic template
I have content pages that give me named regions from the master page into which I put content.
In an event handler for each content page I load data from the database (mostly read-only).
I bind this data to ASP.NET controls representing grids, dropdowns or repeaters. This data all 'lives' inside the HTML generated. Some of it gets into ViewState (but I wont go into that too much!)
I set properties or bind data to certain items like Image or TextBox controls on the page.
The page gets sent to the client rendered as non-reusable HTML.
I try to avoid using ViewState other than what the page needs as a minimum.
Client side (not using ASP.NET AJAX):
I may use JQuery and some nasty tricks to find controls on the page and perform operations on them.
If the user selects from a dropdown -- a postback is generated which triggers a C# event in my codebehind. This event may go to the database, but whatever it does a completely newly generated HTML page ends up getting sent back to the client.
I may use Page.Session to store key value pairs I need to reuse later
So with MVC how does this 'lifecycle' change?
I'll attempt to comment on each of the bullet points you mentioned:
Your master pages still exist in MVC and are used to provide a consistent layout to the site. not much new there.
Your content pages will become views in the MVC world. They still provide the same content areas to your master pages.
The eventhandling of webforms should not be used in MVC, instead your Controller classes and their action methods will handle loading your data into a "model" that gets passed to the view.
Although webform style databinding is possible in MVC, I find that it is not the optimal solution. Better to place your data in a model class and strongly type your view so that you have direct access to that model. Then its simply a matter of using the <%= ViewData.Model.SomeProperty %> syntax to access your data and display it in the desired locations. As for viewstate, my recommendation is to forget that it even exists.
Remember that one of the advantages of using MVC is that you have control over the HTML you send to the client. Embrace that power and try to find solutions that allow you to maintain that control. Webform controls attempt to hide the the html from you and as such make it more difficult to customize the html when you need to.
I would highly recommend JQuery or one of the other similarly powerful javascript libraries. But learn to use them to access the HTML DOM directly and avoid the id mangling issues of webform controls.
You can use jquery to hook into the dropdown selection on the client side and submit standard or ajax style requests. Those request can return new pages, redirects, html fragments or even JSON data that can be used to update the existing page.
The asp.net Session can be used as needed.