Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Couple approaches I could see.</p> <ol> <li><p>Like TheZuck said, instead of navigating to the details page, use a Dialog or Modal window whose content is the details page. With this, you can use JavaScript to access the values from the Index page when the user wishes to navigate. I'm not as big a fan of this idea as it ties your navigation logic to rendered view content that could change.</p></li> <li><p>You could keep the ids you need from the index page and pass them through to the details page. The upshot to this is it'd be a relatively minor bit of code to change for you. On the downside, you'd be posting and retrieving these ids with every navigation request.</p></li> <li><p>You could do like #2 but with the addition of splitting your navigation controls from the details content itself. If you push the details into a partial view, you can now wire your navigation controls using AJAX helpers. Clicking forward would take you to the next id in your local list by issuing a POST or GET to an <code>ActionResult</code> in your controller that would return the partial view bound to the data for that id. I like this method most because it doesn't roundtrip the ids with each details navigation and doesn't require a lot of custom javascript to access ids from a rendered page. It gives you the opportunity to use a loading panel as well in case retrieving your data takes some time to retrieve.</p></li> </ol> <p>An aside: if you really do not like storing your ids in a hidden input field or javascript variable or list, you can always make use of the <code>Session</code> but be careful if you're in a load balanced environment without sticky sessions. This way you have server-side access to the current filtered result. Your navigation requests would just send the current ID and the desired direction to navigate. In your controller, just pull the session, look up the ID and move your pointing forward or back (be careful to wrap-around or else make sure you have a way not to render a navigation button that would cause the wrap).</p> <p>Of the choices, I like #3 the best for best UX especially if the details would be too large to render nicely in a small Modal or Dialog as in option #1. It can be the most responsive as well and, assuming you apply the aside, you have access to POCO representation of your list rather than serializing and deserializing in JavaScript. I would consider #1 if the Details page is so minor that it would easily fit into a Dialog or Modal window. It can be just as responsive as option #1, and you can still use the aside to keep from manipulating the ids in JavaScript.</p> <p>The only reason I down-prioritize option #3 is because our UX person constantly denies client requests for "pop ups" that display the data. She hates them. I haven't figured out if it's personal or because UX best practices inform this decision but that's something I've never excelled at so I have no interest in finding out!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload