I’m sure if the team at the SiebelHub would in their series of ‘snap polls‘ start another poll soliciting for the top most UX ‘inconveniences’ with Siebel OpenUI, will find among the higher ranking issues the fact that the ‘back button’ should be used with great care.
Great care, because any uncommitted data will be gone, forever. Have you just spent half an hour on a lengthy call report? The back button will not commit it for you, rather will throw it away… This very issue comes up again and again.
Although there is no water-tight solution, I have been testing a feasible approach using the undocumented method ‘IsCommitPending’. I found that this method of the business component class tells you whether there is in-flight data.
Just entering following on the browser’s console will tell you, if you have in-flight data:
SiebelApp.S_App.GetActiveView().GetActiveApplet().GetBusComp().IsCommitPending();
That’s actually a pretty cool framework feature, though… undocumented (hence it might change, and don’t try to ask Oracle tech support to provide further guidance…)
The IsCommitPending() returns a consistent output. Once you change any data, it will return ‘true’. The moment you either explicitly commit the data using CTRL+S or the applet menu ‘Save Record’, instantaneously IsCommitPending() will return ‘false’. Also stepping of a record, will implicitly commit the data, hence IsCommitPending() will return ‘false’ too.
So, I marched on. I created a simple applet presentation model as proof of concept to capture all ‘FieldChange’ events. On the first ‘FieldChange’ event I create a floating div with the id=datalossWarning and the default class ‘dataloss-warning-disabled’.
Per CSS pseudo-selector I add a font from the ‘oracle’ font, to serve as indicator.
I further attach a click event, which as part of this proof of concept I added to the presentation model as well. But rather, this should belong in a physical renderer instead… And rather than using the JQuery’s click event, it would be more appropriate to use the Helper class to make behavior consistent across non-touch and touch devices. But that is all for later!
Once the visual check box indicator appears, clicking the same will execute a write record as such:
SiebelApp.S_App.GetActiveView().GetActiveApplet().InvokeMethod(“WriteRecord”);
I choose to make it fade away using a simple transition. The CSS is as simple as effective.
The most relevant lines from the presentation model are presented below. Again, a setTimeout was required to ensure the code to be executed after all other framework code completed. Required to have the IsCommitPending() call to return the correct value. Inspecting the value, drives simply swapping the CSS class from ‘dataloss-warning-disabled’ to ‘dataloss-warning-enabled’ or vice versa.
The complete presentation model ‘CheckCommitPendingPM’ code for a list applet, is not more than a few lines besides the typical framework code required for any presentation model. I choose to use the ‘Init’ event, but likely the ‘Setup’ would have worked as well. Not sure if there is a benefit for either.
I further added a few lines in my existing post loader, to remove the #datalossWarning div every time a new views loads.
A brief demonstration puts the cherry on the cake:
Again, this is a proof of concept. Interested to hear feedback :-)
As from previous readings, you might know that enabling this across the application is due a current framework limitation not that straightforward without possible breaking out of the box functionality. Simply overriding the ‘DEFAULT LIST APPLET’ presentation model, will due to the sequence in which the OpenUI framework loads code will prevent a possible out of the box presentation model to load. So be careful there!
– Jeroen
