Today’s guest writer is Steve Greenberg, a Lead Program Manager on the team. Steve is responsible for form rendering and the new templates in Access 2010.
One of the recurring topics on this blog has been the methods used to navigate a database. A few months ago, we introduced you to the Access 2010 navigation control. We also just recently introduced the BrowseTo macro action.
With Access Services, there is another method of navigating your application, and the good news is that you don’t have to do any work to get it. I’m talking of course, about the browser’s BACK button.
Since the early days of the web, the BACK button, and its less-used sibling, the FORWARD button, have been the most common method users have for navigating websites. However, they present challenges to web application developers. What does it mean to “go back” in an application? Unlike web-sites, applications are not inherently architected with a breadcrumb trail that keeps track of previous states. Here are some additional questions that pop-up once you start talking about running an application in a web browser: What happens when you push the refresh button? Have you ever been frustrated by being sent to the homepage of a website and having to start your work over again? Can you bookmark data you often use to easily return to it later? Can you copy the contents of an address bar, send it to a friend, and have them quickly see the same information you’re seeing?
The answer to all these questions depends on whether the action taken in the web application updates the URL seen in the address bar. When the URL is updated, a new breadcrumb is added to the trail, and the new state of the application can be reconstructed even if the page is refreshed, accessed in the future or pulled up on a different machine.
Certain actions in Access Services update the URL, and certain actions do not. Certain information is reflected in the URL, and certain information is not. Knowing the details can help you optimize applications for the web from the outset.
Before we reveal the secrets of the Access Services URL decoder ring, there’s one concept to explain: At any point in time when using an Access Services application, there is one special form or report – the “key object”. Extensive information about the key object’s data and state is maintained in the URL. Because of space limitations in the URL, little information is maintained about any other currently-open objects. You might guess that the key object is the form or report that is loaded directly in the browser window. But many Access Services applications use a navigation control. For these applications, the form directly in the browser window has no data. As a result, if there are a series of forms and sub-forms, the key object is set to be the top-level form or report that is bound to data.
With this information in hand, let’s look at a sample URL:
URL
Example
Explanation
You specify the server and site name when you publish.
Type=<Object Type>&
Type=Form&
“Form” or “Report”. The type of the key object.
Name=<Object Name>&
Name=MyCF&
The name of the key object.
Path=<Path to Sub Form Control>&
Path=Navigation1.NavigationSubform%3ENavigation2.N avigationSubform&
This is the path of forms and subforms that parent the key object. See the BrowseTo post for more information on Path.
Where=<Where Clause>&
Where=%3DID%3C%3E2&
The WHERE clause applied to the key object.
Page=<Page Number>&
Page=2&
The current page if the key object is a continuous form or current record number in a single record form.
If the current record is the New row, then it is set to *.
DataMode=<DataMode>
DataMode=Edit
The data mode of the key object.
Note that because parameters are URL-encoded,
Office 2007 Keygen, they look funny. (For example, instead of [, you see %3D).
Finally, here’s a list of actions that update the URL: Using the BrowseTo or OpenForm to change the key object, its WHERE clause, page or data mode. Using the built-in First, Previous, Next, Last and New buttons to change the current record or page. Using GoToRecord to change the current record or page. Using SetFilter to change the WHERE clause for the key object.
And here’s a list of actions that do not update the URL: Using OpenForm to open a modal pop-up dialog. Any actions taken within a modal pop-up dialog. Using SetOrderBy to change the order by. Using the datasheet column headers to sort or filter. Scrolling in the datasheet. Changing the current tab in a tab control.
With that information in hand, you can choose to create applications that interact predictably with the browser’s back, forward and refresh buttons.
Enjoy! <div