I'm curious about that implementation. Both on how it is achieved and what you do about the following scenarios:
What happens if a record from a previous found set is deleted
What happens if all records from a previous found set are deleted
What happens if a record was presented in a sorted set, but that record has changed so it sorts differently (do you respect the original record sequence or the place the record where it belongs by respecting the sort)
When users interact with a navigation component that performs a query do they expect the back button to run the query again or do they expect their last query result?
I've always sidestepped something like this because there are so many elements that are difficult to deal with. I also feel like there are cases where 2 users pressing 'back' would expect a different outcome.
Sure- it saves the navigation info in JSON format. Nav info is basically:
Layout
Record UUID
Find
Sort
Obviously the toughest thing here is saving and reapplying finds. A lot will depend on whether you use FileMaker's built in find system. I never do, as I don't like it.
All my finds are performed in custom layouts and/or popups, with my own language instead of "Request" and "Omit" and "Constrain" and so forth. Therefore it's easy for me to capture all find criteria. You can take that as far as you want- for example including manual "omits" of records from found set. I do, but I think you could get away with not.
Anyways, the info is stored in global variables named after the window (so that it works with multiple windows). Pressing back or forward uses the JSON arrays to go to the layout, apply find/sort, and go to record. That includes executing several finds in a row if they're deep into a series of modified finds. And that is of course when back/forward matters most- navigating a chain of modified finds.
As far as the edge case stuff, you can handle that however you like. I simply ask myself "What would happen if they pressed back in their web browser" and try to emulate that behavior. So for example:
Finds/sorts are re-run. If that results in nothing, you can choose what should happen based on your preference (all records, show nothing and give a custom message, etc...).
It was a pain to implement, but it works fast and doesn't have drawbacks from other methods like with the snapshot approach (i.e. 'flashing windows" and desktop only). It's made a huge difference, especially when demoing for new clients.
So am I correct by saying this means you handle the sort commands yourself and the user cannot use the native sort?
I'm ok with finds, I'm not sure I would re-run them or if I would track lists of record IDs. There can be conflicting scenarios:
a list of items each having a status. Finding items to be processed, flagging some as processed. Press back. Press forward. Processed items are no longer shown (because they are not matching the find criteria 'to be processed').
I do a find for active contacts, someone deactivates a contact, I go back, then forward. Maybe I want the query to be re-run (it is what I was looking for, but not the same records I got the last time I was there).
Still, the sort is the most trouble in my opinion, because it cannot be read and you cannot sort dynamically. So I can only assume you have a tight control on the available sorts, in order to be able to restore them when needed.
I don't want my clients seeing any "FileMaker" menus, including the sort menu. When they want to sort, the press a sort button to get a popup. Then then choose from a series of fields (i.e. sort first by: Name, second by: State, etc....). I would not be able to tolerate them seeing FileMaker's "Sort" dialogue with all the table's fields, and all the table occurrences, and all that other stuff (i.e. "Override field's language for sort").
I think that stuff looks bad and compares poorly with how web apps work & look.
This is an older demo, but a decent way to store finds. Performance is decent, and could probably be updated with some features made available since this was made.
I do not like the native sort dialog either, but because sorting dynamically is impossible, any UI we implement also means we are locking the system in some way.
For me the important thing is to cover ~99.9% of scenarios. For us that usually means at most 10 fields with 2 levels of sorting. That can mean occasionally writing a script with up to 90 Else If branches and corresponding stored sorts which sucks, but it's worth it. But for sure- once a year we'll get an email from a client that want's to sort by 5 fields.
I wish the sort step would accept variables with field names.
This is an area where Jeremy Brown has pushed me toward using DataTables ( JavaScript library running in a web viewer ). Solves so many of these issues.