Close page when selection has been made

Version 1
    This document was generated from CDN thread

    Created by: KEVIN BEVERLEY on 09-02-2009 11:22:31 PM
    Dear community,
    We are developing an IP phone application where agents can drill down into a menu and select a state.
    The following happens on the phone:
    -select an option in the main menu (CiscoIPPhoneMenu object), this will show a sub menu
    -select an option in the sub menu (CiscoIPPhoneMenu object), this will populate the status in the call panel (via a CiscoIPPhoneStatus object)
    This works, but both the menu pages remain on the screen which I'd like to be closed after hitting submit. I tried using a CiscoIPPhoneExecute object that calls the status update url and Init:Services. But the latter one closes the app before the status update page has exectued.
    Does anyone know a solution for this problem? Is there another way to call the submit from page to page that closes the current page instead of just loading the new page on top of it?
    Many thanks,

    Subject: RE: Close page when selection has been made
    Replied by: Stuart Gielen on 17-02-2009 05:19:55 AM
    FYI: We've implemented a different design that works around the issue we had:
    We now just call Init:Services to close the application when the user has selected the menu item.
    The jsp that is called by the menu option will update the agent's status. This will  trigger an event that uses the method to update the status panel.

    Subject: RE: Close page when selection has been made
    Replied by: Stephan Steiner on 24-02-2009 02:11:08 PM
    I've recently had to deal with that myself - I've tried various things:
    Using a refresh header in the CiscoIpPhoneExecute (with Key:Services) to have it still refresh and load the CiscoIpPhonestatus.
    Using a refresh header in the page that serves the CiscoIpPhoneStatus object and the refresh url then returning a CiscoIpPhoneExecute object with Key:Services (or Init:AppStatus or the new app management uris which really are the most proper way to do this).
    Sending a CiscoIpPhoneExecute with two actual urls.. one pointing to the page that gets the CiscoIpPhoneStatus and one that points to another CiscoIpPhoneExecute with Key:Services
    It seems that Key:Services means the phone will no longer heed the refresh header. Likewise, when there's an CiscoIpPhoneStatus being sent, the phone also won't heed the refresh header. And if you send two URLs, only one is being executed.
    Thus, none of the above worked. Since we're using JTAPI anyway, we're now going to do a simple rewrite, move the JTAPI part over to the web frontend running on Tomcat and then using it to send the CiscoIpPhoneStatus object to the phone via CiscoTerminal.sendData and then have the web application just return a CiscoIpPhoneExecute with Key:Services. That means writing a simple application that runs upon machine startup and queries the service page until it responds (which initializes JTAPI) rather than having a service that starts the JTAPI app when the machine boots.
    Having tried the above I don't think there's any other approach that is more likely to succeed - so you either have XSI through (J)TAPI or HTTP POST to the phones as Stuart is using.