Developing web applications, despite all the available technologies, isn’t always that easy. The main factor of success or failure is the end user. One needs to make a web application that covers all the possible events that might occur. That consists of tasks like input help, repertories, input validation, navigation and of course saving of data. However, there are also less obvious tasks like foreseeing that a user doesn’t necessary follow the supposed way of entering data. As a web developer, you need to capture these kinds of odds.
One of the things we need to tackle is the user leaving the application, or screen, and losing data by doing so. This can be prevented though in rather simple ways. You will see different possibilities in this web log.
Are you included? Within the Web Dynpro environment, there is the so-called Work Protect Mode to prevent unsaved data or otherwise called ‘dirty state’. This WPM can run in three modes: - No protection
- The application decides whether the application has unsaved data. This is the default mode.
- The application and the HTML Client check the application state
More info and examples can be found in this help . If you don’t have a Web Dynpro application, you can use the state management techniques, explained in an earlier Enemy of the state. Originally, it was designed to clear up all the state info of a stateful application when one left the application. However, one can easily rebuild this principle for data loss prevention. You only need to use the same technique that I am going to explain next. If you don’t have Web Dynpro or a statefull application, or want to check things on page level instead of at application level, there is also a minimal code solution for this.
All you need to do is to put this JavaScript in to the head section of every page
var needToConfirm = false;
window.onbeforeunload = confirmExit;
function confirmExit()
{
if (needToConfirm)
{
return "Changes will be lost if you don’t click on the ‘Save’-button";
}
}
I would recommend putting this code in a separate file, which you retrieve in the head section of your HTML.
You can store it as a MIME type, but this method has it drawbacks. The source is not editable unless you download it, edit in an external application and upload it again. A better method is to save it as a BSP page instead.
Furthermore you can opt to save the head section code in a BSP include if the code remains the same over the pages.
* *
Are you sure? Are you changed?<br>
It could be tuned even finer if you like. Let’s say, you want to warn the user when the value entered is different from the original value. <br>
To give an example:<br>
A user sees a value A for a field and changes it to B. He reconsiders his entry and fills in value A again, in other words the original value. As such, nothing is changed, so you don’t want to warn the user since nothing as such has been changed when you compare the value to the original value.<br>
This can also be achieved in a simple way too.<br>
All you need to do is to call a function that compares the new value with the original value.</p>
<pre>
<input type=”text” value=”<%=some_value%>” name=”a_field_name” onChange="is_changed(‘<%=some_value%>’,this.value)"></pre>
<p>You give two parameters to the function:</p>
<ol start="1" type="1">
<li>The original value that is provided as standard value. This one comes from an ABAP variable too. </li>
<li>The new value that can be retrieved via this.value</li>
</ol>
<p>The function itself</p>
<pre>
<script type="text/javascript">
function is_changed(ori_val, new_val)
{
if (ori_val != new_val)
needToConfirm = true;
}
</script></pre>
<p> </p>
<p>Are you concluded? As you can see, you can make sure that the end user (and ultimately you yourself) don’t lose any entered data by leaving the application or page inadvertently. All this can be done with very little effort.
