An Overview of Instant Web Publishing

Instant Web Publishing (IWP) has been a feature of FileMaker Pro since its introduction years ago in version 4.0. In its earlier incarnations, IWP was never quite the robust tool that one hoped it would be. Its main benefits were that it was extremely simple to enable and configure, and that it turned FileMaker layouts into web pages without any CGI programming or HTML coding. There were, however, many limitations, particularly with the number of layouts you could use and with script behavior, making IWP unsuitable for all but the most basic of web applications.

With FileMaker Pro 7, IWP took a great leap forward, retaining its amazing ease of setup and use, but adding enough features and flexibility that, for the first time, it could be used as part of a serious business application. We think that the new IWP will revolutionize the way FileMaker Pro systems are developed and deployed. Whether you e new to FileMaker Pro development or just haven looked at IWP in a while, its well worth your time to investigate and learn about this tool.

What Is IWP?

Broadly speaking, Instant Web Publishing is one of several options for sharing data from a FileMaker database to the Web. The other options include exporting static HTML, exporting XML and transforming it into HTML with a style sheet, and Custom Web Publishing (CWP), which involves doing HTTP queries against the Web Publishing Engine and transforming the resulting XML into HTML.

The goal of IWP is to translate to a web browser as much of the appearance and functionality of a FileMaker Pro database as possible, without requiring that a developer do any additional programming. FileMaker layouts are rendered in the users browser almost exactly as they appear to users of the FileMaker Pro desktop application. To give you an idea of what this looks like from the users perspective, Figures 21.1 and 21.2 show an example of a layout rendered both in FileMaker Pro and through IWP in a web browser.

IWP is more, though, than simply rendering your layouts as web pages. IWP users have much, if not all, of the same application functionality as do FileMaker Pro users. They can run scripts and view, create, edit, and delete data just like traditional FileMaker Pro users.

IWP Improvements in FileMaker Pro 7

Although FileMaker has moved on to version 8, we know there are still a significant number of systems out there that have yet to move from FileMaker 6 to 7. For that reason, we recap here the main IWP improvements in FileMaker 7, and then go on to discuss the additional enhancements to IWP in FileMaker 8 in the following section.

There were numerous improvements to IWP in FileMaker Pro 7. For those readers who have used IWP in previous versions, well run through some of the most significant changes.

First, there is no longer a configuration wizard where you pick themes and views that determine the look and functionality of a status area. Instead, IWP in FileMaker 7 and 8 has a status area that looks and functions similarly to its FileMaker counterpart. And there are no restrictions on the number of layouts that can be accessed. The only layout restrictions are those that you, the developer, choose to put in place. Well discuss this concept more in the "Designing for IWP Deployment" section later in this chapter.

Another major difference between the old and the new IWP is script support. Previous versions of IWP had severe restrictions on the type and length of scripts that could be run from a browser. Now, more than 70 script steps are supported, and there are no length constraints. We discuss script support in detail later in this chapter as well.

Perhaps the biggest change to IWP in FileMaker 7 and 8 is how its deployed. In earlier incarnations, IWP was part of the Web Companion, which meant that a client copy of FileMaker Pro or FileMaker Pro Unlimited acted as the web host. That client was able to share files that it had opened as a guest of FileMaker Server. Frequently, this architecture proved to be unstable and required a fairly high degree of maintenance.

FileMaker Pro can still act as the host for IWP sharing (for up to five concurrent users), but now, FileMaker Server Advanced can also be a web host. Not only does this server-side architecture allow greater stability and a greater number of connections, but you can also use FileMaker Servers SSL encryption capabilities to better secure your data.

Finally, IWP in FileMaker 7 and beyond is session-based. Well explore this concept more closely later in the chapter; the session capability is one of the ways that IWP is able to function very similarly to the FileMaker desktop application. It allows IWP to have a semblance of persistence in an otherwise stateless environment.

IWP Improvements in FileMaker Pro 8

Authentication is now via an HTML form, rather than via the HTTP authentication used previously. With HTTP-based authentication, the user sees a dialog, presented by the browser, prompting for login information. In FileMaker 8, IWP displays an HTML page with fields for account name and password, and a submit buttonthis is generally thought to be a bit more elegant than the plain HTTP dialog. In addition, the forms-based login allows for the use of a wider range of characters in account names and passwords: Using HTTP authentication, account names and passwords were limited to characters in the ISO-Latin-1 character set, but this is not so with forms-based authentication. In addition, forms-based authentication is potentially more secure because the login credentials are not cached by the browser as they are with basic HTTP authentication. (This additional security can, however, be compromised by the fact that many browsers have a feature permitting you to save forms-based information for later use.) The new forms-based login is shown in Figure 21.3.

Its now also possible to create your own IWP home page, rather than being limited to the default home page displayed by IWP. The IWP home page is generally used as a portal with links to all the databases currently available under IWP. In a later section well discuss how to create your own IWP home page.

The other updates to IWP in FileMaker 8 are a bit more minor. IWP now exactly respects the tab order set in FileMaker 8 (rather than tabbing according to the stacking order, as in FileMaker 7). Its also worth noting that many of the new interface features in FileMaker 8, such as the tab control, tool tips, and calendar picker, are fully supported in IWP. (Custom menus are a notable and probably obvious exception.)

Scenarios for IWP

There are two primary scenarios in which IWP is a deployment option you may want to consider: first, for providing remote users access to your files, and second, for creating or integrating with a database-driven website. In each case, IWP is a less costly and an easier-to-implement choice than alternative options. We think its helpful before diving into the implementation details to have a good understanding of how IWP stacks up against these alternatives.

Remote Users

First, lets consider the idea of providing remote users access to a FileMaker database. By remote, we mean any users who are not physically connected to the same local area network as the FileMaker Pro (or FileMaker Server) application that is hosting a given file. It is certainly possible for remote users to use FileMakers built-in networking to connect to a hosted database, which is of course what users on the local area network would do. The benefits of this are that there are no functionality differences experienced between remote and local users and that you don have any additional costs or development work. The remote users need to have a copy of the FileMaker Pro desktop application, and thats it. The drawback of this as an option for remote users is performance. A networked FileMaker solution is highly network intensive and needs lots of bandwidth to operate well. Remote users may find client/server performance to be unacceptable, especially when using large files and for reporting functions.

One alternative you might consider is setting up Citrix with Terminal Services, or even just Terminal Services by itself, for your remote users. These are both instances of a remote desktop access technology. Essentially, when remote users start a remote desktop access session, their FileMaker Pro applications are running locally on the same network as FileMaker Server, and are hence very fast. All that are shipped across the network are keystrokes, mouse clicks, and screen images. Remote desktop access is an appropriate solution when you have multiple offices or lots of remote users who need to access a centralized FileMaker database, but it comes with a fairly steep price tag and requires not insignificant amounts of configuration and maintenance.

Note

Check out http://www.microsoft.com/windowsserver2003/technologies/terminalservices/default.mspx for more information on Terminal Services. Check out http://www.citrix.com for more information on using Citrix.

Other remote access technologies are also worth considering, such as Timbuktu and gotomypc.com. These can be excellent low-cost solutions for organizations with just a few remote users, but they do not allow multiple simultaneous client connections to a single remote computer.

Instant Web Publishing offers a reasonable alternative both to FileMakers built-in networking and to remote access products as a means of providing database access for remote users. It provides significantly faster access to data than using FileMakers networking, and it comes with much lower cost and maintenance requirements than a Citrix deployment. There are limitations of IWP that need to be weighed against these benefits, but for its functionality, speed, cost, and ease of use, its certainly worth trying.

Creating a Database-Driven Website

There are two general techniques for incorporating data from a FileMaker database into a website. On the one hand, you can create static views of data by exporting HTML or XML from your database. This works especially well for read-only sites where the content doesn change often. For instance, you might want to publish data from an event database on your website. It might be suitable simply to find and export some portion of the data on a periodic basis, and then to move the resulting HTML document to your website.

On the other hand, the alternative to publishing static data is publishing dynamic data, which means that the web user is somehow interacting with the database in real-time. This allows up-to-the-second data accuracy and also enables users to easily add, edit, and delete data directly from their browsers.

Creating dynamic connections from web pages to a FileMaker database can be a complex and time-consuming task. This process is often referred to as Custom Web Publishing (CWP). For now, its enough that you know a few of the pros and cons of CWP. On the plus side, using CWP, you can create robust, complex, and professional web applications. The drawback of CWP is the same as with most web application development: Its a fairly complex skill to learn and is therefore costly in terms of time and/or money.

Instant Web Publishing offers a reasonable alternative to CWP as a means for building a dynamic web application. You can design layouts in your FileMaker solution that fit nicely with the rest of a site, or you can even create a whole website out of FileMaker layouts if you e so inclined. With IWP, you don need to learn HTML or any middleware languages, and maintaining your site is as simple as editing scripts and layouts within FileMaker. However, these strengths of IWP also become its weaknesses when you e attempting to develop especially complex web applications. You have no ability to modify how IWP behaves at a low level: It does what it does, and thats it. You can look under the hood at the code and manipulate it, nor is it easy to mingle IWP-based web pages and data with data or interface elements from other web environments.

Getting Started with IWP

After youve decided that IWP is something you want to try, there isn too much youll need to do to get started. There are two ways to deploy IWP. You can use the regular FileMaker Pro desktop application, in which case you e limited to publishing a maximum of 10 database files to at most five concurrent users. Alternatively, you can use FileMaker Server Advanced, which allows for significantly more files and users. The configurations for these options are covered in detail in the next section.

The host machinewhether running FileMaker Pro or FileMaker Server Advancedof course needs to have an Internet (or intranet) connection. Ideally, it will be a persistent connection (for example, T1 or DSL). The host machine also needs to have a static IP address. If you don have a static IP address on the host machine, remote users can have a difficult time accessing your solution. Finally, any databases you want users to access via IWP need to be open on the host machine.

Tip

Consider setting up a domain name for the IWP host machine. This enables your users to go to something like databases.mycompany.com instead of a difficult-to-remember IP address. Your ISP or a networking specialist can help you with that task. If you ever need to change machines or IP addresses, you can repoint the domain name to the new address without your users being affected by the change.

To access your IWP-enabled files, remote users need to have an Internet connection and a compatible browser. Because IWP makes heavy use of Cascading Style Sheets (CSS), the browser restrictions are important, and are something you need to consider carefully if you intend to use IWP as part of a publicly accessible website.

On Windows, the supported web browsers are Internet Explorer 6.0, Internet Explorer 7.0, and Firefox 1.0. On Macintosh, users need Safari 1.1 (Mac OS 10.2), Safari 1.2 (Mac OS 10.3), Safari 2.0 (Mac OS 10.4), or Firefox 1.0. Obviously, these options may change with new releases of browsers and new versions of operating systems, so consult the www.filemaker.com website for the latest configuration guidelines. Whichever approved browser is used, JavaScript needs to be enabled, and the cache settings should be set to always update pages.

Caution

Some organizations forcibly disable JavaScript in all browsers. If you, or any of your remote users, work for such an organization, be aware of this and its ramifications for your web publishing strategy: IWP will not work unless JavaScript is enabled in the browser.