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.
Related
I have 2 gsp's say, "a.gsp" and "b.gsp".
"a.gsp" have combobox, from which user can select options.
My question is that, if the user shift to "b.gsp" and then come back to "a.gsp", the combobox selected option should be still there.
How to achieve this ?
You can do multiple things to achieve this. Depending on your requirements you may:
Use javascript and cookies.
Pass the value selected in the combobox into the controller when you naviate to b.gsp and into a hidden field in b.gsp, but then you have to pass it back to the controller once more when you want to see a.gsp.
Pass the selected value inside session/flash scope
From your question it sounds like you are not fully embracing Grails' MVC architecture and using controllers correctly to prepare data and pass structured data through to your view.
To begin with, rename your controller actions and views to something meaningful rather than a,b. Even if just for testing a small sample, as taking shortcuts can lead to long term bad habits...
Secondly, if you are using a tag then you would use the value attribute to indicate what should be selected.
Read about the tag and its attributes here : http://grails.org/doc/2.1.0/ref/Tags/select.html
Give us more details and perhaps we can help.
Thanks for the clarification, so I'm assuming that there could be any number of ways a user might leave the current a.gsp page and come back, but whatever happens you want the browser to remember the selected option. In this case I would use the jQuery cookie library, its very small, won't impact performance as you're doing very litte work and should be very quick for you to setup.. See: https://github.com/carhartl/jquery-cookie
Set a cookie in an onChange handler based on your selects val() value.
When your page loads (document ready), if you get a value when reading the cookie, then try and set the select value.
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.
I am trying to conceive of a way to store a list of selected items to the session, for later use. I've googled and read examples for 2 hours now, and haven't found any examples that work.
The basic idea is this. User sees a list of items to act upon. User selects a number of them. User chooses action to perform. Controller takes list of selected items, and begins to act on them.
Am I thinking about this wrong? It makes sense to me to use an Ajax action to store the 'select/unselect' action on the session object. I really don't want an entire database object to handle this. I just want a simple list of selected objects. In classic ASP, I'd just have reacted to the selected items in a form post, but that doesn't seem right in asp.net mvc....
How do I construct this behavior (with or without the Ajax, but preferable without the DB access)?
I don't get it, why not bind directly an array of bools or something directly to your view's list of checkboxes? You can get them as parameters in your controller function and act upon them directly, with no middleman, they'd just be another POST value.
Or even better when you send in your list of items as part of your model, make them a structure that has a bool selected=false field that is bound to the checkbox next to the label, and you'll get the results back in your model directly.
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.
Here's a simple problem: users want to edit products in grid-like manner: select and click add, select and click add... and they see updated products list... then click "Finish" and order should be saved.
However, each "Add" have to go to server, because it involves server-side validation. Moreover, the validation is inside domain entity (say, Order) - that is, for validation to happen I need to call order.Add(product) and then order decides if it can add the product.
The problem is, if I add products to order, it persists changes so even if users do not click "Finish" the changes will still be there!
OK, I probably shouldn't modify the order until users click Finish. However, how do I validate the product then? This should be done by the order entity - if product is already added, if product does not conflict with other products, etc.
Another problem, is that I have to add product to order and "rebuild view/HTML" based on its new state (as it can greatly change). But if I don't persist order changes, the next Add will start from the same order each time, not from the updated one. That is, I need to track changes to the order somehow.
I see several solutions:
Each time the user click Add, retrieve order from database, and add all new products (from the page), but do not persist it, just return View(order). The problem is I cannot redirect from POST /Edit to GET /Edit - because all the data only exists in the POST data, and GET lose it. This means that Refresh page doesn't work in a nice way (F5 and you get duplicated request, not to mention the browser's dialog box)).
Hm, I thought I can do redirect to GET using TempData (and MvcContrib helper). So after POST to /Edit I process business logic, gets new data for view, and do RedirectToAction<>(data) from MvcContrib that passes data via TempData. But since TempDate is... temp... after F5 all the data is lost. Doesn't work. The damn data should be stored somewhere, this way or another.
Store "edit object" in Session with the POST data (order, new products info). This can also be database. Kind of "current item - per page type". So page will get order ID and currently added products from this storage. But editing from multiple pages is problematic. And I don't like storing temp/current objects in Session.
Marking products as "confirmed" - if we do /order/show, we first cleanup all non-confirmed products from the order. Ugly and messy logic.
Make a copy of the order - a temporary one - and make /Edit work with it. Confirm will move changes from temp order to persisted. A lot of ugly work.
Maybe some AJAX magic? I.e. "Add" button won't reload page but will just send new + already added products to server, server will validate as order.Add(products + newproduct) but will not persist changes, will just return updated order information to re-build the grid. But Refresh/F5 will kill all user-entered info.
What else?
Is this problem common? How do you solve similar ones? What's the best practices?
It depends a lot on how you implement your objects/validation, but your option number 5 is probably the best idea. If AJAX isn't your thing, you can accomplish the same thing by writing the relevant data of already-added-but-not-saved entries to hidden fields.
In other words, the flow ends up something like this:
User enters an item.
Item is sent to the server and validated. The view is returned with the data entered by the user in hidden fields.
User enters a second item.
Item is sent to the server, and both items are validated. The view is returned with the data for both items in hidden fields.
etc.
So far as F5/Refresh killing entered data... In my experience this isn't too much of a problem. A more pressing concern is the back/forward buttons, which need to be managed with something like Really Simple History.
If you DO want to make the page continue to work after a refresh, you need to do one of the following:
Persist the records to the database, associated with the current user in some way.
Persist the records to session.
Persist the records to the query string.
These are the only storage locations available that persist through both redirection and refreshes.
If I were you, I would come up with something which resembles option 5. And since you say that you are comfortable with Ajax you can try this. But before you do this, you should move your validation logic outside the Order.Add() method. Maybe you can move it to another public function called Validate() which returns a bool. And you can still call the same Validate() in the Add() method, thereby doing the necessary validation before you add the order.
Try to do the validation on the client side. If you are using jQuery, you can use the jquery validate plugin. But, if this is not possible for some reason (such as when you need to validate stuff against a database). You should do your validation on the server side and just return a JSON object with the 'success' boolean flag and an optional message, just a way to mark that the data is valid. You would allow the user to add a new product only if the previous Order was valid.
And when the user hits finish send the product to the server and do the validation again, but persist the order in this round-trip.
Now, If I had a complete say in this, I wouldn't even go to the extent of doing validation whenever a product is added/edited. I would just do the validation whenever the customer hits finish. That would be the simplest solution. But, maybe I am missing something.