NOTICE: Our Community is moving. Get more information. Updated information on a New Login Process
Sometimes a web page may have a different startup page depending on when the user logs in, who is logged in etc. An example of these may be;
While testing client-server applications SilkTest has built-in recovery system components for dealing with objects such as these (the wStartup data-member); when working with Web pages it is a bit more challenging, as there is no easy way to deal with them.
The Recovery System As we already know DefaultBaseState works with the wMainWindow object in the following way:
The challenge with this process, in this situation (where a DialogBox or a different Web page loads on request), is in step 1 of the recovery system: when attempting to load the Web page, the recovery system expects that Web page to be loaded. And it might not be if a Login page sometimes loads first for the user to enter information into. Or, if the page does actually load but a DialogBox appears over it, in step 3 of the recovery system the DialogBox will be closed in the most efficient way without any regard for actions that may need to be taken, such as clicking OK.
Login Web Pages This is perhaps the most common problem that users have. In many Web sites, the user is issued a non-persistent "cookie" (meaning that it disappears as soon as that instance of the browser is shut down) when they login. When they return to the site in the same browser session, they will not be prompted to login again, as their "cookie" is still available with their authorization. For SilkTest, this means that trying to load the actual Web page will sometimes not work as the login page appears.
The easiest way to deal with this problem is a bit unorthodox, but not as unorthodox as modifying the recovery system files directly - which is always a bad idea (since the files will be updated in the next product release). When the DefaultBaseState wants to load a Web page, what Web page does it decide to load? wMainWindow is, of course, the Web page, but it then retrieves the sLocation data-member from the wMainWindow object, which should be the URL for that Web page. However, there"s another way to use sLocation: as a property.
The property that has been created will look exactly like a data member and can be called in the same way. The property could be created in whichever way is required and have additional verification such as how to deal with login pages as shown above.
The following steps will be taken now when the DefaultBaseState is called: