Runtime components : Channels components : HTML Channel : Tasks : Preventing duplicate order posting
  
Preventing duplicate order posting
You may want to prevent the toolkit from processing a Web page that users access using their browser's back button. For example, to prevent a duplicate sales order, you will want to prevent the toolkit from processing the page that processes a sales order if the user returns to that page using the back button.
HtmlProcessor has a status called consequential and also has the following attribute, conseqErrorPage:
<htmlProcessor id="creditCardsProc" context="creditCardsCtx"
conseqErrorPage="conseqError.jsp">
HtmlState has the following attribute called conseq, which is a boolean (true or false):
<htmlState id="confirmationPage" type="page" typeIdInfo="confPage.jsp"
conseq="true">
The conseq attribute determines if the status of the HtmlProcessor will be set to consequential.
HtmlTransitionDescriptor has the following attribute called conseq, which is a boolean (true or false):
<htmlTransition id="confirmationPage.ok" conseq="true">
The conseq attribute determines if the status of the HtmlProcessor will be set to consequential.
During the lifetime of the user session, the system maintains a counter that increments whenever a new page is processed. When the HtmlProcessor activates the HtmlState of the page, the system identifies it using the value of the counter (this identifies the order in which pages are displayed).
If the HtmlProcessor does not have "consequential" as its status, the system processes all HtmlStates (pages) normally. The HtmlProcessor attains consequential status when the system processes an HtmlState that has the conseq attribute set to true and it has returned control to the client, or when the transition used to arrive at this state has the conseq attribute and it is set to true. The HtmlProcessor loses consequential status after it processes an HtmlState that does not have the conseq attribute or has it set to false.
When the HtmlProcessor has "consequential" as its status, the toolkit is prohibited from processing a page that sends an HtmlState that does not have the conseq attribute or has it set to false. This is an illegal switch. If this situation occurs, the toolkit displays the page defined by the HtmlProcessor conseqErrorPage attribute.
For example, a user browses to the Web site. The system identifies this first page as 1. The HtmlState associated with this page has a conseq attribute and it is set to false. The user clicks a link that goes to another page (identified as 2). The second page is associated with another HtmlState, which does not have the conseq attribute. The next page (3) is associated with an HtmlState with the conseq attribute set to true. When the HtmlProcessor processes the third page, the page's state is activated and the processor's status is set to consequential. The browser then displays page 4 (the user does not try to send this page so its associated state has not yet been processed). If, from the fourth page, the user presses the browser's back button, the system first checks if the page to be displayed in the browser comes from using the back button. It does this by comparing the identifier of the last page processed (3) with the identifier of the page to be processed (1, 2, or 3).
The following list describes the resulting behavior of the HtmlProcessor depending on how many times the user clicks the back button.
1 The user clicks the back button once. The browser displays page 3. The user tries to send this page. The system first detects that the page comes from the use of the back button (last page processed = 3, page received=3). As the processor's status is consequential, the system looks for the conseq attribute in the received state (corresponding to page 3). As the state has the conseq attribute (its value does not matter for this check), the switch is legal and the page is processed.
2 The user clicks the back button twice. The browser displays page 2. The user sends this page. The previous processed page was 3 and current page is 2, so the system checks the status of the processor. As it is consequential, the system checks the state's conseq attribute. The state associated with Page 2 does not have conseq defined. This is an illegal switch and the state is not activated. The user instead sees the page defined within the processor as the conseqErrorPage.
3 The user presses the back button three times. The browser displays page 1. The user sends this page. The previous processed page was 3 and current page is 1, so the system checks the status of the processor. As it is consequential, the system checks the state's conseq attribute. As the state has the conseq attribute defined (its value does not matter for this check), the switch is legal and the page is processed.
If the user presses the back button from any other page than page 4, the system is able to process every page because the processor's status is not consequential. It is only set to consequential when page 3 is processed (note that the user actually sees page 4). This is the page whose state has the conseq attribute set to true.
Go up to
Tasks