Visual LANSA Forum

A lot of our users are complaining about hitting the back space in VLF-ONE and it taking them back a page like the back button.

I recognize that this is a browser issue and that Chrome removed that "feature" and FireFox has a way to disable it. IE and Edge however still behave that way and a lot of our users STILL use IE 11.

This post viewtopic.php?f=3&t=2117&p=5672 pointed me to the SYS_WEB.CloseQuery and using VLF-ONE already has an event handler to terminate the framework.
I thought I may be able to use this to ask the user if they meant to close the page, however there does not seem to be a way to get the response from the user, so even if the user selects cancel, it still kills the VLF-ONE session.

For example, if I modify the above the handler as such The prompt displays, yet,if the user selects "cancel", the VLF-ONE.uTerminate is still invoked.

Normal javascript confirm boxes have a boolean that refers to the user response, so I've tried to do something like this But this still does not stop the page from closing.

Any way to gracefully handle this?

It would be nice if SYS_WEB.CloseQuery included a canceled boolean or something to indicate what the user chose, or a way to cancel the page navigation.

Thanks,
Joe

This is a classic SPA application issue.

As an experiment try this cut down version of the code:

evtroutine handling(#SYS_WEB.CloseQuery) querystring(#pQueryString)

#pQueryString := "Are you sure you want to leave the page?"

endroutine

That eliminates a "clean" shutdown of VLF-ONE but maybe that does not matter.

Or maybe like this:

Begin_Com Role(*EXTENDS #PRIM_WEB) Layoutmanager(#WebFormLayoutManager)

Define_Com Class(#PRIM_ATLM) Name(#WebFormLayoutManager)
Define_Com Class(#PRIM_ATLI) Name(#VLF_One_AttachItem) Parent(#WebFormLayoutManager) Attachment(Center) Manage(#VLF_ONE)
Define_Com Class(#VF_AC006O) Name(#VLF_ONE) Parent(#COM_OWNER) Height(800) Width(1200)

Define_Com Class(#Std_Int) Name(#URLChangeCount)

* -------------------------------------------------------------------------------------
Evtroutine Handling(#COM_OWNER.CreateInstance)

#VLF_ONE.uInitialize Frameworkidentifer("VF_VLFONE_SYSTEM") Logonhandlerid(VF_AC026O) Passwordchangerid("") Mtxtloaderid(UF_OMULTI) Themecustomizerid("") Logonexpiry(90) Logonheaderpanelid(UF_OHEADP) Logontrailerpanelid(UF_OTRALP) Showrestartbutton(True) Usebadges(True) Materialdesigndefault(True) Usesidebarmenus(False) Usepaneltransitions(False)


Endroutine

* -------------------------------------------------------------------------------------
Evtroutine Handling(#Sys_web.URLChanged)

#URLChangeCount += 1

If ((#URLChangeCount > 1) AndIf (#VLF_ONE *IsNot *null))
* Cancellation is not possible from here so always use possibletocancel(False)
#VLF_ONE.uTerminate Possibletocancel(False) Browserisclosing(True)
Endif

Endroutine


* -------------------------------------------------------------------------------------
Evtroutine Handling(#SYS_WEB.CloseQuery) Querystring(#QueryString)

#QueryString := "Are you sure?"

Endroutine


End_Com

Also I think that the application is launched from a desktop icon it starts with no browser history.
So the back key and back button are logically disabled because there is no where to go back (or forward) to.

If I just leave the querystring in place and DO NOT call uTerminate then it works.
I'm assuming then that this is safe to do, not calling uTerminate when the page closes.

Joe

I guess so - unless you are using RAMP and want to to get your 5250 sessions cleanly closed.
You could not use the restart button option either I think.
It could become problematic in the future or restrict the use of some new feature of course.

What about starting from a desktop icon so that the browser has no history to go back to?

We are having a serious think about putting full back (and forward) button support into VLF-ONE.

Do you have comments/opinions/ideas about how it should be behave?

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 instead of names could use identifiers.

User selects a person (instance list item) and url becomes 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. 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

Thanks Joe.