Hello all, I'm seeing some odd behavior in a new application we've built in Mx6, and I'm not certain whether it's a bug, normal behavior in Mx6 or if I'm simply overlooking something. Here's the situation: We have a search functionality in the application. When completed, the logic opens a search page with a non-persistent 'Search' object as caller of the page, with a set of associated, non-persistent SearchResults. Each SearchResult object has a *--1 association to an actual database object 'File' that contains the data that the user is looking for. [Search] 1--* [SearchResult] *--1 [File] The list of SearchResults are displayed in a listview, with a 'listed-to-grid' dataview that shows the SearchResult details, and allows the user to click on a button to open the attached File. File opens in a new fullscreen page. Basic stuff, and all this works fine. However, when the user is in the 'File' page and hits back / backspace, he/she is returned to the search page, but the caller object 'Search' and all associated objects are gone. The page is empty. The Mendix documentation for Mx6 states: Non-Persistent Objects that are used in the browser will remain in the cache as long as you can still navigate to them using your browser back and forward buttons. Objects from a pop-up are garbage collect as soon as you close the form, but Objects in content could remain available. When you open forms sequentially the user will always be able to use the back/forward buttons in the browser unless you close any previous forms. I've checked and double-checked, but all I do from the Search page is open the new File page. I never close the Search page, and the user is able to return to it using backspace. The documentation seems to suggest that the Search object should then still be available, and I seem to recall this has always been the case in earlier versions. I'm considering several workarounds, but they all seem rather invasive for something this basic. So, a bug? Or have I simply overlooked something? Any insights are welcome!
asked
Christiaan Westgeest
2 answers
1
Christiaan,
As you describe the behavior this seems to be a bug.
What you try is to change the non persistent entities to persistent entities and make sure not to commit the data.
In this way the same functionality can be accomplished (as the data is created non persistent), but the garbage collection might act differently.
The change would be rather trivial and non-invasive.
answered
Erwin 't Hoen
0
Okay, so it was a bug, but the bug was my own. Sometimes it pays to take a good night sleep and look at things with clear eyes.
Turned out there was a subflow in the GET flow for the Search object in the top bar (so always present) that would clear away older Search objects and set an empty one for a new search query. This GET was also triggered when opening the details page for File, so it would remove the old Search object.