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.
Related
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.
I'm developing ASP.NET MVC 4 application, that will be used to configure a complex application. I want to have one configuration page, with multiple tabs. Each tab will be used to configure a different part in the system, and when you click on it the right form (each configuration tab will be a different partial view) will be loaded with AJAX. I want to have "Save Changes" button in the bottom of the page, that will save the changes from the whole tabs.
Since the system itself is modular, I want to make the configuration site modular too. Which means, that i want each tab to be some kind of a plugin that expose to me the following methods (by inheriting from an interface): GetConfigurationPartialView (which will return the partial view with the view model for this tab), SaveChanges (which will save the configuration to the DB as a draft), and GetConfigurationXml which will export the full XML configuration and apply it on the system.
My questions are:
What do you think about that design? do you have better ideas?
How do you recommend to implement this one "Save Changes" button in the main view? How can I iterate all of my plugins and call each plugin's SaveChanges method, pass it the correct model object (which is the partial view's model) filled with all the data without having intimate knowledge of each plugin object in the main controller/view so i can keep this system easy to extend?
Some of the tabs includes grids with data. i started looking into Kendo UI grid. I want to let the user do everything on the grid, in the client (deleting and add new rows), and then i want in the SaveChanges method i wrote about to get list in the server side of all the changes that the client did (for example, in pseudo code: changes[0]={Action = Delete, ProductID = 1}, changes[1]={Action=New, ProductID=1, Name="aaa" }). How can i do it?
Thanks.
Just make a partial view for each configuration page and load it as needed. I concur KISS is best.
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.
I'm looking to build a rails web app with an admin control panel. I'd like the control panel to use a tabbed interface for controlling users, projects, tasks etc, and I'd like to switch between tabs using jquery tab UI controls with ajax. Also using restful authentication for users and my own code for projects, tasks etc.
Here's what I can't wrap my head around. Normally, I'd have a controller for each tab, so validation is simple, if there's an error (say in the user) i just render the proper action with the object and it's errors and we're set. However, if I'm not refreshing (to different controllers between tabs) how does this work? Do I need to have one massive controller with all the user, project, task validation and controls (ie. crud operations)? Seems like not the greatest design.
Or is there some way I can use an 'admin' controller that encompasses separate controllers for proper crud/error checking etc.
Hope this makes sense?
I would make the contents of each tab be called in by a separate ajax request. This would give you the following benefits
Now each tab can easily be a different view/controller
You only need to load the contents for a tab when it is used; you won't be processing code/downloading html for tabs that the user doesn't use.
If you don't want to use this route, (i.e. you feel you need to load all the contents of the tabs on page download in a single request) then you could separate out the code using helper methods and partials. See my answer here: Rails Sub-controllers?
I would personally use inline validation in the forms. Jquery does that pretty well , but there are a lot of library that can help you with that.
I guess it's not exactly what you were looking for, but it would make your job easier. Of course still keep validation in the models so that no one can bypass the validation (using firebug or something like this)