I have an edit form in MVC. It contains different fields and 3 different partial views which is used like usercontrols. The scenario in these partial view: they contain a list with edit and delete plus an add button that when these buttons click a dialog box pop ups which contains a few related fields.
My main question is that what is the best solution to temporary save the changes of the lists(like viewstates)?
I'm asking because the main edit page contains more fields and I want in the case that the save button in the form is pressed, the whole data can be saved in database!(the tables in partial views has foreign key of the table of the main page).
Thank you in advance!
The web is stateless in its nature. Instead of looking for a workaround on the whole ViewState thing, it's better to try and embrace the medium you're using.
If you have many controls rendered on the same page you can either:
Use HTML5 Local Storage and persist on the client before submitting the whole form. There are many frameworks that will help you persist a form on the client side like Sysyphus.js
Make use of asynchronous ajax calls if you need to persist data on user input before submitting the whole form. Client-side calls can be managed using jQuery's ajax() function with ease and you can make use of the ASP.NET Web API to build the end-point on the server.
Related
I am wanting to edit a number of rows in a model in a grid. I would really like to be able to edit "inline" ie within the grid rather than going off to another page via another controller.
I know about the "Web Grid" which seems lean, but I believe it needs to go over to an edit page.
In the first instance I am wanting to focus on server solutions for simplicity. Also I would want the control to respect the validation data annotations in the View Model.
Many thanks,
Ed
You can render your own grid for a table of data and include a form within it to allow the user to edit a particular row. You will need to implement typical grid features to control this process, such as row selection, insert, edit, update and possibly delete. There are plenty of good models from Web Forms world you could work to, including but not limited to MS and Telerik controls.
If you are going to make extensive use of such grids in your applications I would recommend wrapping up this functionality in an HtmlHelper extension that accepts a table of data and the configuration options you need as arguments.
http://datatables.net/ is a very good jQuery grid. Try it out.
also other options
kendo: http://demos.kendoui.com/web/grid/index.html
jqgrid. http://jqgrid.com/
I am developing an application in ASP.NET MVC structure.
I was wondering, I am trying to create a site that only has one page, it has a navigation bar on the left (Which is a list of user input), and then the main content in the middle.
My question is, can I make the navigation bar (The user input list) static, and make the main content change, based on the user input, with an asynchronous AJAX postback? I would have multiple controllers which would set different results to the main content, based on the user input.
How would I go around doing so, partial views and calling actions with asyncpostback's?
Yes, I would do exactly as you have suggested - have actions that render PartialView([name]) and use, probably, jQuery's ajax to fetch the content.
You can then use jQuery to inject the html into the content panel.
Where it might get interesting is if you need to have css added to the head section of the page.
But then, with diligent use of a single CSS, or at least a single group of CSS files, you can sidestep that.
Be aware though, that it does complicate form post-backs if the dynamically injected content has forms. You would need to hijack the form submit process and turn it into another ajax call to get the resulting html into your content panel - you might even need to hand-crank the form submission because I don't think you can trigger form submission as an Ajax operation.
I've done a similar thing with named iframes (doesn't necessarily need script), as you can render a form with a target which is equal to the name of an IFrame; and it means that the iframe content can be a full view instead of a partial (and therefore has full control over its own script and css). Of course, then you have issues with sharing data between the host page and that frame.
I'm after some design advice.
I'm working on an application with a fellow developer. I'm from the Webforms world and he's done a lot with jQuery and AJAX stuff. We're collaborating on a new ASP.MVC 1.0 app.
He's done some pretty amazing stuff that I'm just getting my head around, and used some 3rd party tools etc. for datagrids etc.
but...
He rarely uses Submit buttons whereas I use them most of the time. He uses a button but then attaches Javascript to it that calls an MVC action which returns a JSON object. He then parses the object to update the datagrid. I'm not sure how he deals with server-side validation - I think he adds a message property to the JSON object. A sample scenario would be to "Save" a new record that then gets added to the gridview.
The user doesn't see a postback as such, so he uses jQuery to disable the UI whilst the controller action is running.
TBH, it looks pretty cool.
However, the way I'd do it would be to use a Submit button to postback, let the ModelBinder populate a typed model class, parse that in my controller Action method, update the model (and apply any validation against the model), update it with the new record, then send it back to be rendered by the View. Unlike him, I don't return a JSON object, I let the View (and datagrid) bind to the new model data.
Both solutions "work" but we're obviously taking the application down different paths so one of us has to re-work our code... and we don't mind whose has to be done.
What I'd prefer though is that we adopt the "industry-standard" way of doing this. I'm unsure as to whether my WebForms background is influencing the fact that his way just "doesn't feel right", in that a "submit" is meant to submit data to the server.
Any advice at all please - many thanks.
The thing you need to take into consideration is how the application will work if javascript is not available. You should strive to ensure that the basic functionality works without it. This is called progressive enhancement or unobtrusive javascript and is considered a best practice.
http://en.wikipedia.org/wiki/Progressive_enhancement
The way you should do it is to use a form with a real submit button and then hijack that form to use ajax if the User Agent supports it. This is usually pretty trivial to do using the jquery forms plugin. In your action method, you can check to see if the incoming request is an ajax request by checking the Request.IsAjaxRequest property. This is set by MVC automatically on requests that have the X-Requested-With header set to XMLHttpRequest. Then you would return a full view or just some json based on that.
Here's a short screencast demonstrating this: http://www.youtube.com/watch?v=YQsFR1rkgMU&feature=player_embedded
Both solutions are viable, though using submit buttons will make your application more accessible (i.e. JavaScript will not be required in order to use it).
You could also do the both - start with a page that has all the necessary logic using postbacks, and "upgrade" it with nice AJAX-y requests and animations. This way, users with JavaScript will get the eye candy, and the page will gracefully degrade when when a user without JavaScript visits the page, falling back to the postback mechanism.
In our old system we had pages rendered from XSLT. In order to change the page into "edit" mode we would have a button of some sort, once clicked would have an EditYN flag which would be passed to the stored procedure. The stored procedure would simply give this variable back to indicate that the page was in edit mode. This meant that query strings, viewstate or session data were not required to indicate that the page is in edit mode.
I've been dealing with ASP.NET MVC only for the last week for RND purposes at work. I'm wondering what's the best way to have a page which displays data, to then turn into a page where you can edit all of that data? Should you move to a separate page? Should you stay on the same page and have rendering logic in the view to show the edit mode of the page?
Whilst on the same topic, I thought I'd also ask about GridViews and their place in the MVC architecture. Beforehand we'd simply use data sources and set them up with the GridView. Then the GridView could enter edit mode quite easily by itself with the UPDATE query set in the data source. How should this process be done using MVC?
Make a submit button for your edit mode. The controller action will respond to POST, set the "InEdit" flag in your model, then return the same view again. The view can then render based on the flag. But I would rather create two different views, for view and edit modes, then based on the flag analysis done in the controller action just return the one or the other view.
Whilst on the same topic, I thought
I'd also ask about GridViews and their
place in the MVC architecture.
How should this process be
done using MVC?
You can use javascript, something like jqGrid or Yahoo´s datatable. For simpler datatables, you can use jQuery´s tablesorter.
On the backend, your controller returns json objects that can be modified by the client, ie. the javascript grid which then sends the data back to the controller to be saved.
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.