[Carlos Pero]

I know this is a challenge for Web-based interface, but I figure GroceryCRUD is doing a lot of the magic and rendering already, perhaps there were hooks to make it happen.

People who regularly work with Microsoft Access and forms are accustomed to being able to page through results on the edit form. That's because Access is keeping the results of the query in memory and can give the user links to go "next next next" and load each row into the form.

This may be easy to recreate on the Web if the ids are sequential and the "next" button simply adds +1 to the id currently being edited, but that won't be the case with a real dataset with different ids and certainly a filtered query.

To explain the example, imagine I have a table with 1000 records, and I made a CRUD interface with a "where" clause where it pulls a subset of 100. I'll be showing the user 25 at a time in the list view. Let's say the first 3 results are rows #3, #12, and #20.

In the List view, the user clicks "edit" to edit the first results, which is row #3. It looks good, and they want to see the next row. They click a "next" button, and the interface knows to retrieve and show row #12.

To make this work, the Edit page needs to know what the query was for the List view. (Re-sorting the list view makes this even more difficult, just beware.) Normal Web pages that are programmed to edit a single row just don't know the context of the query that led the user there. But is it possible somehow with GroceryCRUD?