Oh man, that would be nice!
I know that other frameworks (Angular, React, Ember, Vue etc.) have solved this, but I don't know how they have done so.
I don't know how you would make the underlying details work but these are my thoughts from a VLF-ONE developer perspective.
I think that each Application / Object / Command change should trigger a change in the URL.
I don't think changing url with Filters would be super useful.
Thinking out loud here, so bear with me.
Lets take an example of the Resources Application.
Resources
-- Object: People
---- Filter: Search
---- Command: Details
---- Command: Notes
-- Object: Places
---- Filter: Search
---- Command: Details
---- Command: Notes
A user selects Resources / People. Url could show something like
Code: Select all
../UF_OEXEC.html?App=Resource&Object=People
instead of names could use identifiers.
User selects a person (instance list item) and url becomes
Code: Select all
../UF_OEXEC.html?App=Resource&Object=People&Command=Details&keys=ComputedHashOfKeys
The ComputedHashOfKeys is problematic as we need to take all the possible key values (akeys, nkeys etc.) and create a hash based on those values. I don't think deconstruction is all that important, as the Framework already knows about all the keys, we just need a unique identifier to enable the url change state. Speaking of which, could be done with a simple Guid. Each call to avListManager.AddToList could generate a unique RowId (or instance id) as a Guid and instead of keys we could use RowId. This way each instance selection change, would have a new RowId which in turn would create a unique URL.
Code: Select all
../UF_OEXEC.html?App=Resource&Object=People&Command=Details&RowId=33d895af-4e2d-4a69-a392-431248bd0add
That should handle creating URLs for Application / Object / Instance / Command structure.
Navigation now, is about going back the URL stack translating the structure from the URL to focus the individual windows or instances.
So that if the user goes from Resources / People selects a user, then selects another user, then Details, selects Notes then hits back, Details becomes the active command. Pressing back again focus moves to the instance list and the selected Person. (Command window probably still open). Back again selects the previously selected instance (as identified by the row id in the url). Back again and the url does not have the RowId so instances are selected and the Filter windows has focus. It seems to me that we should be able to navigate back through history through every Application / Object / Instance / Command selection.
Forward navigation would be about going up the URL stack changing the focus windows / instances accordingly.
I am concerned about state. I am assuming each window keeps its own state the same way RPs do when we do this in VLWeb. However I know that keeping too many windows open causes a perf issue and if a user closes a window, the window loses its state. (at least I think it does, could be wrong here). If that is the case, then the window cannot be navigated to which causes a problem. I have no idea how to solve this problem as it would require all the selected identifiers / data in the url to rebuild the window state.
At this point I would not attempt to create "bookmarkable" urls, i.e. with all the identifiers required on each URL to rebuild the state after login. However that may be the way to solve the above state issue, but then creates more problems of its own.
I think it would be easier to deal with if VLF-ONE did not have the window concept. So that each object essentially became a page as in a traditional web app. That page could have different layout options, and you plug your components into that layout. In this way your focus items are reduced to the commands. This does, I think, require a Router like those found in Angular, React etc. I assume it would also require a significant change to VLF-ONE which is probably not in the cards. Perhaps a VLF-ONE v2...
I keep coming back to the thought that if we had something like a Router in these other frameworks, that it would solve quite a few of these issues. After all they already solved this problem and it works really well. Doing something like this, we could define our own paths, or VLF could define the paths, and we plug in components and the required query parameters.
I know this is a really difficult problem to solve and really appreciate ya'll looking into it.
Thanks,
Joe
