let's assume i have the following structure:
pageA.xhtml - Here we can select an item which will be needed within pageB and pageC but not in pageE.
pageB.xhtml - Here we use the Item which was selected from pageA. We
also have a selectBox and some Buttons on this page.
When selecting something from the selectBox some Buttons will be deactivated and some Text can be displayed.
(when refreshing this page we want the same state again). pageB includes
pageD which lists some stuff. Now we can navigate to pageC.
We also create some objects which are only relevant for pageC but not for other pages.
pageC.xhtml - here we get the object from pageB and depending on some User input we modify it and when we press apply we come back
to pageB which displays
our changes. From pageB we can press save which will save the changes and pageD (which is included in pageB) will be
updated.
pageD.xhtml - just lists some stuff. (will only included within pageB)
pageE.xhtml - This page will start something completely differend and does not need the input from pageA but you can navigate directly
to pageC. In this case pageC has to
hide some things.
I hope the example is somehow clear. Actually i just made it up to make my question a bit clearer: I want to know what the best practises are to pass data between different pages and save the actual state (also have the same state when coming back).
Also how to reset/clear data which are needed in some pages but not in different ones.
For example some data will be needed for several pages but some only within nested pages (in an optimal world the data within the nested pages should be cleared when leaving them)
Of course i could save stuff i need into the session, but then i have to be careful to remove those stuff again when i don't need it anymore. JSF and CDI support Conversations. But the problem here is that it is not possible to have nested conversations. Of course i also could pass everything with request parameters .. but in this case i have to be careful if i have ajax requests within my page (i guess i would have to send always all parameters).
I'm using JSF 2.0 with CDI. Any answer will be appreciated. Sadly i cannot provide any code example .. so i hope i was able to express my self clear enough.
greetings kukudas
You could create a new CDI scope or recreate the ViewScope in CDI. Take a look at CODI conversations as well.
Related
I have a simple view that displays some customer details in a list. The user can filter down the list using drop downs and text boxes to show results they are interested in and then JQuery/AJAX is used to return a partial view and update the list. For each item in the list there is an edit button which takes the user off to a different action to edit that specific item. When they save or cancel the user is directed back to the customer details page but the filters they had applied have obviously reset back to default. I was wondering what the standard way would be to tackle this seemingly common problem in the MVC world?
Thanks.
As HTTP is stateless protocol , it's your responsibility to remember the state of the page. One of the way we do is show the additional detail on clicking the Edit button on the same page in popup . It will solve the problem in case you are ready to make the design change.
Otherwise you have to use the standard state management technique , like Session or Cache on the Server to remember previous search state or you can append some key value in the URL it self and when user cancel , recollect the state from the URL query string .
One more way if security is not concern is using the Cookie to store the previous selection on the client machine if it is very specific to user.
Just use Session to persist their filters. It tends to be overused by inexperienced developers but the situation you describe is pretty much exactly what it is for.
One way is to fake the update of current row.
Consider, You clicked a delete button to delete the row.
Now with jQuery-
$.get(url,data,function(data){
if(data.success){
$('row').fadeOut(300,function(){
$(this).remove(); //<--- This is what I mean
});
}
});
Here you have removed the row on the basis of Json result and your page didn't need any refresh.
Also as in your case, Just load the edit Partialview at the same page by managing some space.
You can do this at least.
First, I apologize if this is a dumb question, but I'm new to MVC and am trying to get up to speed as quickly as possible. I have spent hours searching for answers and even went and bought a book on MVC 4, but it still didn't answer my question.
I have a form I'd like a user to fill out to add a new product to the catalog. They choose the category, enter the name, a description, etc.. On the same page I'd like them to be able to add sizes or product options such as Small, Medium, Large, etc.. The problem is I'm not sure how to go about this.
I need to temporarily store the size options for example in some sort of collection until the user actually 'saves' the product, then I need to be able to read the collection. What I'm trying to avoid is to have the user add the basic product info, then save it, then select it, then choose to add options to it. I'm trying to just do it all on one form. Any help would be greatly appreciated!
There is nothing preventing you creating a view model with its own collections for the detail items and have those mapped to some sort of javascript control for selecting multiple items such as one that writes to an mvc hidden form control.
The controller handling the postback will simply create the master model from the postback data (the updated view model) and then create the child records. The whole thing could be achieved with ajax calling a controller action that returns a partial view of the updated ui.
Similar to this but have the list as a property of the master model
http://www.stevefenton.co.uk/Content/Blog/Date/201002/Blog/How-To-Handle-Multiple-Select-Lists-In-ASP-NET-MVC/
A little more advanced on how to manage your own bindings http://www.dotnetcurry.com/ShowArticle.aspx?ID=584
Sounds like u need to roll your sleeves up and get a control written in javascript that allows child items to be added client side whist serializing e.g. Into json when they save and saving it to an mvc hidden control ready for postback. Use json.net to hydrate these values into your pocos. http://erraticdev.blogspot.co.uk/2010/12/sending-complex-json-objects-to-aspnet.html
On Telerik demo site we can see an example of how to implement kind of functionality: "check all checkbox in a grid's column". But in my case it has 2 disadvantages:
It didn't check all checkbox on all pages.
It didn't save a state of checkboxes on different pages.
Is anybody know how to resolve these issues? Thanks in advance.
As long as I know there's no built-in functionality to do so. The same problem happens when you select records on page one and change to page two, you loose whatever you selected before.
To achieve that functionality you have 2 options (I've used both on previous projects)
1) On each check make an Ajax call to one of your controllers and store whatever you selected on a Session Variable (This can be inefficient if you have a lot of records)
2) Create a javascript variable and store your selections there, and send back to the controller using a json variable or a comma separated values string
As I said, I've used both approachs so it depends on if this works for you or not
Hope it helps
I can't test this, so I'm not 100% sure, but looking at Telerik's example, one reason it's not persisted is because every "page" of the grid requires a postback, and in the controller action result method, they aren't passing in the model (or view model) for the items that are bound to the grid, they're only returning that list of items back to the view, so it will never "save" which items are checked/selected and which ones aren't. You should be able to get around this by making your view model a parameter into the HttpPost action result method and then passing that list back to the view after the post so that it retains which items are selected instead of creating a new one. This won't solve the issue with not selecting all the items, but it should at least retain which ones are selected throughout the pages. I think the reason for it not working with all items is it can only select the ones that are actually being displayed at the time. You may want to do a post (or ajax) to select "all" items.
One of the major reasons for using paging in grids is so that you don't have to retrieve all of the data from the data store and generate a lot of HTML to push to the client.
It's been my experience that most users understand that a "select all" check box only checks the items on the current page. I've not seen a site where checking such a check box would actually check all records, even those I can't see.
If you have an action which will affect more than the current page of records, I would suggest that you add a button which clearly indicates that the action will affect all records, then send a command to your data layer which will perform that action. This will perform better (you don't have to send a potentially long list of ids across the wire) and allow users to understand the repercussions of their action.
While there are similar questions here, none gave a complete answer, so I am posting a new one.
I have a paged grid - jqgrid - which receives data from server by ajax, N rows (10, 20 and so on, depending on the user selection) each time. There is a boolean value in the grid row model, which is transformed into a checkbox in the displayed row.
When user checks the checkbox and then navigates to the next grid page, the state of the checkbox is obviously lost. What is the best approach to save it? Neither of the possibilities that I see fully satisfies me:
I can save the ids of the selected instances into a global javascript object on checkbox click. Thus when new dataset is obtained, I can iterate through all received instances looking for already selected ones. However this can mean a lot of javascript operations and possible slowdown for the final user, if there are a lot of selected instances.
I can store the selection on the server (session, database, whatever else). This way each time the model is generated, I will populate its boolean parameter with an adequate value. However, this can mean that when the user navigates away from my page without submitting the changes and then returns back, the record states will be restored. I am not sure whether this is good. Generally, I am strongly against storing anything on the server side before user submits the form.
So, what would you choose / offer?
I am using ASP.NET MVC 2.0, C# 4.0, if that matters.
Your question is essentially about preserving state in an ajax scenario that does not involve the evil webforms viewstate.
However, there is nothing wrong with viewstate when it is used to preserve state in the kind of scenarios you are working on (as opposed to providing a means to pretend a web page is a winform).
So, why not go for the best of both worlds and store the values in an encrypted hidden field, a sort of lean, mean, smart man's viewstate?
When you request the next page of data, pass back to the server the existing "viewstate" (if any) plus the new checked items, decrypt the viewstate on the server, see what is in there and if it is relevant to the next page, add the new list of checked items, encrypt that and send the new "viewstate" back to the user.
I haven't done this, so it is just an idea. However, it is logically feasible, and very practical. I say I haven't done this with a grid, but I have done it, with huge success, to design a wizard framework that works a dream.
My wizards preserve their state whilst the user is filling in the forms and only in the final step does anything get persisted (if at all, depending on what the app requires).
This framework is based on the wizard described in Steve Sanderson's book, but extended to work seamlessly with or without ajax. And with a very simple API for controllers derived from my wizard controller.
The code that makes this viewstate work is called from an OnActionExecuting method:
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
var serialized = Request.Form["wizardData"];
if (serialized != null) // Form was posted containing serialized data
{
WizardData = (TModel)new MvcSerializer().Deserialize(serialized);
}
}
And then in the ViewResult returned to the user:
<%= Html.Serialize("wizardData", Model)%>
In your case, as you are just paging data, you would need to serialize and encrypt the equivalent of the wizardData object and send this back with the JSON data to store somewhere in a hidden field.
This is a bit vague, as a wizard is a not a grid of paged data. But the principles (essentially, roll your own viewstate) do apply to both scenarios.
I have addressed this very situation by writing a list of the 'selected' checkboxes in a hidden div when the next page is selected. That way the client maintains the selection list, and no server interaction is required. In addition, when the user finally submits the page, I simply iterate over all the checkboxes in the visible page and the hidden div.
In my system, even in examples where users select hundreds of items, performance is not an issue.
I have an application that has two dependent dropdown lists, where if the user selects a value in list box A, it updates the available set of inputs in list box B. Such as make/model of a car. when the user selects the manufacturer, the list of models would update accordingly.
In winforms, this would just be handled in the autopost back event. What technique/approach should I take in asp.net MVC? is done through AJAX ? just trying to get up to speed on MVC and looking to build strategies to handle common tasks I am asked to handle at work.
I wanted to thank everyone who contributed to answering this post.
I'd do this through ajax. If you have these controls:
<select id="makes" /> and <select id="models" />
then you can do this with jquery:
$().ready(function() {
$("select#makes").change(function() {
var make = this.value;
$.getJSON('models/list?make=' + make, function(data) {
//load 2nd dropdown with result
})
});
});
Then you'd just need an action on the ModelsController called List() that returns a JSON data structure.
That you are using ASP.NET MVC is somewhat irrelevant. You basically have three options for this type of UI mechanic on a web page.
If the data in your lists is relatively small and infrequently changing, it can be easiest just to pre-load all possible data on the page in the initial request either in something like a javascript array or hidden elements in the page markup. When the value of Box A changes, javascript just replaces the contents of Box B with the appropriate data. This all happens without any requests back to the server which makes it very fast. But this method breaks down when the size of your data impacts the response time of the initial page load.
If the data in your lists is large or frequently changing (within the time frame a user would be on the page making a decision), the legacy method is to just have the page get reloaded with the new query arguments when the value of Box A changes. Code on the back-end adjusts the output based on the new arguments. Depending on how complex the rest of the rendering code in your page is, this can be expensive.
This is a variation on option 2 and is basically the answer Ben Scheirman gave regarding ajax. You're still loading the contents of Box B on demand when Box A changes. The difference is that you're only reloading the piece of the page that has changed rather than the entire page.
Personally, if your data is small enough to use option 1, that's probably what I would go with due to its performance. Otherwise go with option 3, particularly if you've already got other ajax related things implemented already. Option 2 is seems to be considered a legacy mechanic by many people these days.
Functionally it would work to place those two drop lists in their own partial view and then return just that when the value in ListA is selected. If that isn't feasible for layout purposes, then Ben's method above looks good.