Designing for IWP Deployment
The preceding section discussed how to enable IWP at the application level and how to set a file so that users can access it via IWP. Although this is enough for IWP to function, there are usability issues to consider as well. Not all layouts and scripts translate well to the Web, and some FileMaker features simply don work via IWP. This section discusses the constraints that you, as a developer, must be aware of when deploying an IWP solution. We also discuss a number of development techniques that can make an IWP solution feel more like a typical web application.
Constraints of IWP
Most of the core functionality of FileMaker Pro is available to IWP users. This includes being able to view layouts, find and edit data, and perform scripts attached to buttons. There are, however, a number of FileMaker features that are not available to IWP users. Its important to keep these points in mind, especially when trying to port an already existing solution to the Web:
- IWP users have no database development tools. This means IWP users can create new files; define tables, fields, and relationships; alter layouts; manage user privileges; or edit scripts.
- IWP users can use any of the FileMaker Pro keyboard shortcuts. Be sure that you leave the status area visible or provide your users with ample scripted routines for tasks such as executing finds and committing records.
- There is no capability to import or export data from an IWP session. In general, any action that interacts with another application, the file system, or the operating system is not possible via IWP.
- IWP has no Preview mode. This means that sliding, subsummary reports, and multicolumn layouts, all of which require being in Preview mode to view, are not available to IWP users. Similarly, printing is not supported. IWP users can choose to print the contents of the browser window as they would any other web page, but the results will not be the same as printing from FileMaker Pro. (That is, headers and footers won appear on each page, page setups will not be honored, and so on.)
- There are a few data-entry differences for IWP users. For instance, web users can edit rich text formatting in fields. That is, they can change the style, font, or size of text in a field. They can generally, however, see rich text formatting that has already been applied to a field.
- Most window manipulation tools and techniques do not translate well to IWP. The users browser can show only the contents of the currently active window in the virtual FileMaker environment. That environment can maintain multiple virtual windows and switch between them, but a user can have multiple visible windows in the browser, and cannot resize or move windows except to the extent allowed by the browser (in other words, the users can manually resize their browser windows, but precision movement and placement of windows using script steps such as Move Window is not supported in IWP).
- None of the FileMaker Pro toolbars are available via IWP. IWP does offer its own toolbars in the status area, however, and these contain some of the same functionality found in the FileMaker Pro toolbars.
- Spell-checking is not available via IWP.
- Many graphical layout elements are rendered differently, or not at all, on the Web. This includes diagonal lines, rounded rectangles, rotated objects, ovals, and fill patterns. The sections that follow discuss this topic in greater detail.
- IWP users can edit value lists through a web browser.
- There is no built-in way for users to change their passwords via IWP, even if they have the privilege to do so. If you need this sort of functionality, you need to use the account management script steps and come up with your own scripted routine.
Scripting for IWP
One of the greatest recent advances in Instant Web Publishing is script support. In versions of FileMaker before version 7, only a handful of script steps could be executed from the Web, and scripts could be no more than three steps long. Under those severe restrictions, it was quite difficult to build anything but the most basic web applications.
IWP in FileMaker 7 and 8 supports more than 70 script steps, and scripts can be of any length and complexity. Also, because IWP is now session-based, scripts that are executed from the Web operate within what might be thought of as a virtual FileMaker environment. This means that changes to the environment (active layout, found set, and so on) are persistent and affect the browser experience, which is a good thing.
Even though IWP script support has come a long way, there are still some behaviors, constraints, and techniques you should be aware of.
Unsupported Script Steps
Given the great number of supported script steps, its easier to talk about whats not supported under IWP. In general, anything that requires that the user interact with a dialog box is unsupported, as are any steps that interact with the operating system or other applications.
The list of unsupported steps is shown in Table 21.1.
Additionally, the option to perform with a dialog is not supported in a number of supported script steps. These include Delete Record/Request, Replace Field Contents, Omit Multiple Records, and Sort Records. These steps are always performed without a dialog via IWP, regardless of which dialog option has been selected in ScriptMaker.
ScriptMaker itself has an option that makes identifying unsupported script steps quite easy. When you check the Indicate Web Compatibility check box, all the unsupported script steps are dimmed. This affects both the list of script steps and the steps in whatever script you e viewing. Figure 21.10 shows an example of what script step dimming looks like. The Indicate Web Compatibility check box has no effect other than showing you which steps are not supported; how you choose to use that information is up to you (although unsupported script steps are dimmed out, you can still add them to a script). Additionally, its status is not tied to any particular script. That is, it is either turned on or off for the entire file, and it remains that way until a developer changes it. We point this out explicitly because the check box right next to it, Run Script with Full Access Privileges, is a script-specific setting.
Figure 21.10. When writing scripts that will be used via IWP, turn on the Indicate Web Compatibility check box to dim out incompatible script steps.
Error Capture
The outcome of running a script (from the Web) that contains unsupported script steps depends on whether the Allow User Abort setting has been turned on or off. If its not explicitly specified, a script executes on the Web as if Allow User Abort had been turned on. So not specifying any setting is the same as explicitly turning it on.
If user abort is on (or not set at all), script execution halts when an unsupported step is encountered. Steps before the offending script step are performed as normal. If youve chosen to log script errors, the offending step is logged as an error in the application log. The user does not see any error message or have any knowledge that anything is amiss.
If user abort has been turned off, a script will simply bypass any unsupported scripts and attempt to perform subsequent steps. Its performed as if the offending step were simply not there. No error is logged to the application log when this occurs.
Script steps with the unsupported "perform with dialog" options discussed earlier are not affected at all by the error capture setting. These script steps will always be performed as if Perform Without Dialog had been checked, regardless of error capture.
Committing Records
If a script run via IWP causes a record to be altered in any way (such as using a Set Field script step), be sure that you explicitly save the change by using the Commit Record/Request step sometime before the end of the script. If you don , your web user will be left in Edit mode and, provided that the status area is visible, will have the option to Submit or Cancel the changes, which is likely not an option you want to offer at that point. Canceling would undo any changes made by the script.
Startup and Shutdown Scripts
If you have specified a startup script for a file, it is performed for IWP users when the session is initiated. Similarly, IWP also switches to a particular layout on startup if youve selected that option.
The shutdown script is performed when the user logs out, even if the logout is the result of timing out.
Caution
The startup script executes only once per session, when the user navigates there from the Database Homepage (or follows an equivalent link from another web page). The startup script is not run if a file is activated through the performance of an external script.
Performing Subscripts in Other Files
A script can call a subscript in another file, but that file needs to be open and enabled for IWP for the subscript to execute. Calling a subscript does not force open an external file, as happens in the FileMaker Pro desktop application.
If your subscript activates a window in the external file, the IWP user sees that window in the browser. Unless you provide navigation back to the first file, a user has no way of returning, except by logging out and logging back in. You should make sure that any record changes are fully committed before navigating to a window in another file. Its possible that the record will remain in an uncommitted, locked state, even though the IWP user has no idea this has occurred.
Testing for IWP Execution Within a Script
If you have a solution that will be accessed by both FileMaker Pro desktop users and IWP users, chances are that theyll use some of the same scripts. If those scripts contain unsupported script steps, you might want to add conditional logic to them so that they behave differently for IWP users than they do for FileMaker users. You can do this by using the Get (ApplicationVersion) function. If the words Web Publishing are found within the string returned by this function, that means the person executing the script is a web user. Its not possible to discriminate between an IWP user and a CWP user with this function; you simply know you have a web user. The actual syntax for performing the test is as follows:
PatternCount (Get (ApplicationVersion); "Web Publishing")
Layout Design
Most layouts you design in FileMaker Pro will be rendered almost perfectly in a web browser via Instant Web Publishing. IWP does this by using the absolute positioning capability of Cascading Style Sheets, Level 2. The CSS requirements of IWP are the reason there are browser restrictions for its use. Weve already mentioned a few layout elements that don translate well to IWPwell recap them here as wellbut there are several additional things to keep in mind when creating or modifying layouts for IWP use.
Graphic Elements
Rounded rectangles, ovals, diagonal lines, rotated objects, and fill patterns are not rendered properly in the web browser and should be avoided. In some cases, IWP displays altered versions of the objects; in other cases the objects simply do not show up.
Figure 21.11 shows a test layout in FileMaker that we filled with various shapes and objects; Figure 21.12 shows how it renders in a web browser. As you can see, IWP does a great job with vertical and horizontal lines of varied widths, with rendering nonstandard fonts, with overlapping text, and with stylized boxes. However, it completely ignored the circle and diagonal line, and altered the rotated text, rounded rectangle, and fill pattern. Also, multicolumn check box and radio button fields don maintain their columnar alignment.
Figure 21.11. Its important to be aware of which layout elements don render properly via IWP.
Figure 21.12. Most elements of the test layout render properly in a browser, but a few are displayed either differently or not at all.
Tab Order
 | In IWP in FileMaker 7, the tab order you set for a layout within FileMaker did not carry over to the web browser. Instead, tab order in the browser was determined by the stacking order of the fields on the layout, with the backmost field being first in the tab order. There was no quick and easy way to see or edit the stacking order within FileMaker; mostly you needed to use the Arrange, Send Backward and Arrange, Bring Forward commands to rearrange things manually. |
Happily, this has changed with IWP in FileMaker 8. IWP will now respect the tab order established in FileMaker.
Caution
IWP does not support the field behavior options to go to the next field by using the Return or Enter key rather than the Tab key. Navigation from field to field in IWP occurs only via the Tab key, just as it would for any browser-based form.
"View As" Options
Web users have the same ability that FileMaker desktop users have to switch between View As Form, View As List, and View As Table on a given layout, unless you restrict that ability at the layout level. To do so, go into the Layout Setup options, shown in Figure 21.13, and simply uncheck any inappropriate views. The additional Table view options that can be specified all translate well to IWP, except for resizable and reorderable columns.
Figure 21.13. In Layout Setup, you can specify the views to which a user should be able to switch for a given layout.
You should be aware of a few special characteristics of List and Table views in IWP. By default, View As List shows a set of at most 25 records, and View As Table shows a set of at most 50 records. You cannot change these settings. Also, while in List or Table view, whenever a user clicks on a record to edit it, the active record jumps to the top of the set. This can be slightly disconcerting for users who are habituated to working with lists of records in FileMaker. For instance, if a user is viewing records 610 of a set as a list, and clicks on record 8, record 8 jumps to the top, and the screen then displays records 812.
 | To learn how to build your own Next and Previous navigation routine for use with List and Table views when the status area is hidden, see the "FileMaker Extra: Building Your Own Next and Previous Page Buttons" section of this chapter, p. 666. |
Layout Parts
IWP can render any and all parts that compose a layout. There are a few differences, however, between how and when parts display in IWP and how and when they display in the FileMaker desktop application.
First of all, in Form view, the vertical size of a part displayed via IWP is the size that the part was defined to be. It doesn stretch to fill the vertical space. This is different from how FileMaker Pro behaves. In FileMaker Pro, the last visible part expands to fill any remaining vertical space. Say, for instance, that you have a layout that consists of only a single, colored body part. Via IWP, if a user resizes a browser window so that its larger (vertically) than the body part, the space between the bottom of the part and the bottom of the browser is a white void. This also means that if your layout has a footer part, it won necessarily (indeed, won likely) be displayed at the very bottom of the browser window.
View As List in a browser also has some differences from its FileMaker counterpart. In FileMaker, a header or footer part is locked on the screen at the top or bottom. The area in between displays as many body records as space permits. In FileMaker, leading and trailing grand summary parts display in List view, but title header, title footer, and subsummary parts do not (in Browse mode).
As weve mentioned, in a browser, List view always contains 25 records (except, of course, when the found set is fewer than 5 or if the active record is one of the last four of the found set). The header and footer are not fixed elements as they are in FileMaker. If the 25 records of the list take up less than the full browser window, the footer simply shows up in the middle of the screen; if they take up more than the full window, a user would need to scroll to see the footer. Another major difference is that title header, title footer, and subsummary parts are all visible in the browser at all times (in List view). Even if the database is sorted properly, however, subsummary parts do not show correct valuesthey show the same values that a leading or trailing grand summary would show. For this reason, its unlikely to be a good idea to allow your IWP users access to layouts that contain subsummary parts.
Container Fields
You should know about a few special restrictions and considerations when using container fields in an IWP solution. Most important, there is no capability to add or edit data in a container field via IWP; these fields are strictly view-only. Entry and updating of pictures, sounds, QuickTime movies, files, and objects is available only to regular FileMaker Pro users.
The visibility and/or accessibility of a container fields contents are dependent on the types of objects they are and how they were entered into the container field in the first place:
- Graphic images that have been directly stored in a container field (that is, not stored as a reference) are visible through a browser. Images should be stored as pictures, not as files.
- Graphic images that have been stored as a reference are visible to IWP users only if the images are stored in the web folder of the FileMaker Pro application (if FileMaker Pro is the IWP host) or if they are stored in the root folder of the web server (if FileMaker Server is the IWP host).
- QuickTime movies can be accessed directly from the web browser. If you insert them as files rather than as QuickTime, however, a user can play or download them.
- Files stored directly in a container field are rendered to an IWP user as a hyperlink. Clicking on the link begins a download of the file. No icon or other graphic representation of the file is visible to web users.
- Sounds that have been stored directly in container fields cannot be played via IWP.
Application Flow
Weve discussed many of the technical limitations and details of how various FileMaker features translate to the Web. We turn now to more practical development matters. There are certain routines and development habits that work well in the FileMaker desktop application that don work as well from a web browser. The following sections discuss how the constraints of IWP will influence how you develop solutions.
Web-based applications generally have a different application flow than FileMaker applications, and you may consequently find that you need to rethink some things when you share a solution to IWP. By application flow, we mean broadly how a user actually interacts with the application. For instance, one of the typical flows for web applications is search->hitlist->detail. Think about google.com or amazon.com and how those sites make heavy use of this pattern. A user enters search criteria; sees a list of matching records, usually in groups of 10 or 20 at a time; and then drills down to a detail record by clicking on a link from the hitlist.
Such an application flow is rare in FileMaker solutions. More often, users spend most of their time on a detail record. They drop into Find mode when they need to locate records. They then flip through the records one by one, or perhaps they switch to a List view where they can scroll through to locate a particular record. An application flow like this can indeed work via IWP; our point is merely that its not a traditional web application flow. Depending on your solution and your users experiences, they may expect a more weblike flow.
When it comes down to it, weve discovered that its actually easier to make FileMaker mimic the web flow than the other way around.
Tip
If you e designing a new solution and you know that youll have IWP users, you might consider thinking about how you would develop the solution if it were a web application. Because there are more constraints placed on designing for the browser, anything you build for the browser should work well for FileMaker users as well.
Explicit Record Commits
Many of the application flow differences described in the preceding section stem from the fact that HTTPthe underlying protocol of the Webis a stateless protocol. This means that every request a browser makes to a web server is separate and independent from every other request. Put differently, the web server doesn maintain a persistent connection to the web client. After it has processed a request from someones browser, it simply stands by waiting for the next request to come in. To make HTTP connections appear to be persistent, web programmers need to add information to each request from a single client, and then let some piece of web server middleware keep track of which client is which, based on this extra request data. This technique is referred to as session management.
The client/server connection between FileMaker Pro and FileMaker Server is persistent. The two are constantly talking back and forth, exchanging information and making sure that the other is still there. FileMaker Server is actively aware of all the client sessions. When FileMaker Server receives new record data from any client on the network, it immediately broadcasts that information to all the other clients. And when a user clicks into a field and starts editing data, FileMaker Server immediately knows to consider that record as locked, and to prevent other users from modifying the record.
The fact that IWP is now capable of performing session management means that FileMaker maintains information about whats happening on the Web in a virtual FileMaker environment. Even though this doesn change the fact that HTTP is stateless, using sessions gives IWP a semblance of persistence. Essentially, the server stores a bunch of information about each IWP user; each request from a user includes certain session identifiers that enable the server to recognize the IWP guest and to know the context by which to evaluate the request. One of the benefits of this session model is that IWP users can lock records, and they are notified if they try to edit a record that a regular FileMaker Pro user has locked.
Still, the statelessness of the Web makes the application flow for something even as basic as editing a record much different in IWP than it is in FileMaker. In FileMaker, of course, a user just clicks into a field, makes some changes, and then clicks out of the field to commit (save) the change. On the Web, editing a record involves two distinct transactions. First, by clicking on an editable field or using the Edit Record button in the status area, the user generates a request to the server to return an edit form for that record and to mark the record as locked. As we discussed earlier in this chapter, Edit mode in the browser is distinctly different from Browse mode.
The second transaction occurs when the user clicks the Commit button in the status area (or clicks a similar button youve provided for this purpose). No actual data is modified in the database until and unless the record is committed explicitly.
This transaction model for data entry may feel very alien to users who are accustomed to working with a FileMaker interface. As you evaluate the web-friendliness of existing layouts or build new layouts for IWP users, try to make the application flow work well as a series of discrete and independent transactions. One common way to do this is by having tightly controlled routines that users follow to accomplish certain tasks. For instance, rather than letting users just create new records anywhere they want, create a "new record" routine that walks users through a series of screens where they enter data and are required to click a Next Screen or Submit button to move forward through the routine.
Lookups and Portal Filters
Because of the transactional nature of the Web, two common FileMaker development toolslookups and portal filtersdon work well in IWP.
Consider first how a lookup works in FileMaker. When a value in a trigger field is edited (usually by a user), the values of one or more target fields change. For instance, when you e creating an invoice, its typical to enter a Product ID for a line item and have a description and price for that item appear as soon as the user exits the field. Its not important here whether the description and price are actually looked up or are simply related fields. The point is that from a user perspective, exiting the field caused something to happen.
| For more on lookups, see "Auto-Entry Field Options," p. 78. |
When using IWP, to trigger an action such as a lookup or the display of related data, a user must actually submit the change as an edit to the trigger field and then wait for a reply. It works, but its a far cry from being able to just Tab out of a field and have data appear.
Portal filters exhibit the same behavior. The typical portal filter works by having a user choose some value in a field that anchors one end of a relationship. After the selection is made, the portal data immediately updates to reflect the matches to the filter. When using IWP, the user would again need to explicitly submit the entire record, including the filter value, for the portal to refresh.
| For more information about creating portal filters, see "Filtered Portals," p. 489. |
As a more weblike alternative to triggered events like these, you might consider calling explicit attention to the fact that something needs to be submitted before the user can continue with entry. For instance, Figure 21.14 is an example of a layout for creating a new invoice. Notice that as step 1, users are asked to enter a customer ID and to click Submit. After this is done, the related customer data is displayed, and the user moves on to step 2, where they e asked to enter the product code of an item to add to the invoice. Behind the scenes they e actually entering a value into a global field at that point; the Add button creates a related line item record, filling in the description and quantity, and then returns users to Edit mode so that they can enter another product. By leaving users almost perpetually in Edit mode, youll cut in half the number of transactions they have to trigger explicitly during repetitive data entry like this.
Figure 21.14. If you have a routine that requires triggered events, make the submission of the triggers a very explicit part of the process. That is, draw more attention to the triggered events rather than less.
Hiding the Status Area
As when designing a solution for FileMaker users, you have the option to leave the status area visible for your IWP users or to hide it from them. And as with regular FileMaker, unless you lock it open or closed, users can toggle it themselves.
By default, the status area is visible for your IWP users. The script step Show/Hide Status Area enables you to programmatically control the visibility of the status area. Typically, if you want to hide the status area, you do so as part of a startup script.
There are certainly benefits to having the status area visible. Most important, the status area provides a wealth of functionality for the IWP user. Navigation, complex searching, and a host of record manipulation tools are all features that come for free in the status area. Also, the status area heightens the "FileMaker-ness" of the user experience. If one of your goals is to make your IWP deployment feel like FileMaker to your users, the status area can certainly help you accomplish this goal.
There are also reasons that developers want to hide the status area from users. The first is simply to constrain users activities by forcing them to use just the tools you give them. This is generally why developers hide the status area for FileMaker desktop deployments as well. Hiding the status area also makes your application more weblike. If you are using IWP alongside an existing website or plan to have the general public access your site, youll probably want to hide the status area. Public users are more likely to expect a web experience than a FileMaker experience.
If you do decide to hide the status area, you must provide buttons in your interface for every user action you want or need to allow, including committing records, submitting Find requests, and logging out of the application. Because users have no keyboard shortcutsincluding using the Enter key to do things like submit Find requests and continue paused scriptsand no pull-down menus, youll probably need even more buttons than you would when designing without the status area for FileMaker users.
Portals
Instant Web Publishing does an astonishingly good job of displaying portals in a browser, complete with scrollbars, alternating row colors, and the capability to add data through the last line of a portal (providing, of course, that the underlying relationship allows it). Another nice thing about portals in IWP is that you can edit multiple portal rows at once and submit them together as a batch.
When designing an IWP application that requires displaying search results as a list, consider whether you can use a portal instead of a List view. A portal gives you flexibility as far as the number of records that are displayed, and you can use the space to the left or right of it for other purposes. Figure 21.15 shows an example of what a search results screen might look like if you used a portal instead of List view.
Figure 21.15. For many search results screens, a portal makes a good alternative to using List view to display the found records.
The best way weve found for having a portal display an ad hoc set of records (such as those returned by a user search) is to place all the record keys of the found set into a return-delimited global text field (using the Copy All Records script step), and then to establish a relationship between that field and the files primary key. Because you can let the portal scroll, you don strictly need to create Next and Previous links, but it would make your application more weblike if you did. One option to do this is to take the return-delimited list of record IDs and extract the subset that corresponds to a given page worth of IDs. The MiddleValues function comes in handy for this task. Youd simply need to have a global field that kept track of the current page number. Then the function
MiddleValues (gRecordKeys; (gPageNumber-1) * 8 + 1; 8)
would return the eight record IDs on that page. Substitute a different number of records per page in place of 8, of course, if you want to have a hitlist with some other number of records on it. The scripts to navigate to the next and previous pages then simply need to set the page number appropriately and refresh the screen.
Note
To see the example from this section in action, locate PortalExample.fp7 on the CD-ROM accompanying this book.
Creating Links to IWP from Other Web Pages
The IWP Database Homepage provides a convenient access point for entering web-enabled databases. Its possible also to create your own links into a file from a separate HTML page, which is perhaps more desirable for publicly accessible sites. To do this, you simply create a URL link with the following syntax:
http://ipaddress:portnumber/fmi/iwp/cgi?-db=databasename&-loadframes
Caution
This syntax is different than it was in versions of FileMaker prior to version 7, so be sure to update external links if you e upgrading an IWP solution from FileMaker 6 or earlier.
If you are using FileMaker Pro itself as your IWP host (as opposed to FileMaker Server Advanced), you can place static HTML files and any images that need to be accessible to IWP users in the web folder inside the FileMaker Pro folder. The web folder is considered the root level when FileMaker Pro acts as a web server. If you had, for example, an HTML page called foo.html in the web folder, the URL to access that page would be the following:
http://ip address:portnumber/foo.html
If you develop a solution that uses FileMaker Pro as the host and later decide to migrate to FileMaker Server Advanced, you should move the entire contents of the web folder (if youve put any documents or images there) to the root folder of your web server.
Creating a Custom Home Page
| In FileMaker 7, if you accessed IWP via the default path (as opposed to navigating directly to an IWP-enabled database via a hard-coded path like those described in the preceding section), you would always be taken to the same IWP home page (depicted earlier in Figure 21.9). With FileMaker 8, you can override the default page with a page of your own devising. The new file must be called iwp_home.html. It can be used when serving files via IWP either from FileMaker Pro (in which case it belongs in the web directory inside the FileMaker Pro application folder) or from FileMaker Server Advanced (in which case it belongs in the FileMaker Server/Web Publishing/iwp folder). |
There are several approaches to creating such a file. You could devise your own file from scratch, creating your own look and feel, and populate that file with hard-coded links to specific databases, as described in the preceding section. Or, if you want a file that dynamically assembles a list of all available databases, the way the default home page does, youll want to customize the default page. An example of that default page can be found on the FileMaker Pro product CD. (For the curious, it can also be found in the FileMaker application folder: On Windows its found in Extensions/Web Support/Resources/iwpres, and on Mac OS its found in Extensions/Web Support/FM Web Publishing/Contents/Resources/iwpres. On Mac OS, Extensions/Web Support/FM Web Publishing is an OS X package, not a directory, so youll need to right-click on it and select Show Package Contents in order to drill deeper.) The default page makes heavy use of JavaScript and in particular of JavaScript DOM function calls, so familiarity with those technologies will be desirable if you want to customize the IWP home page.
