Instant Web Publishing-An Overview

Instant Web Publishing ”An Overview

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 utterly simple to enable and configure, and that it turned FileMaker layouts into Web pages without any CGI programming or HTML coding whatsoever. 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.

In FileMaker Pro 7, IWP retains its amazing ease of setup and use, but for the first time, it has enough features and flexibility that it can be used as part of a serious business application. We think that the new IWP will revolutionize the way that FileMaker Pro systems are developed and deployed. Whether you're new to FileMaker Pro development or just haven't looked at IWP in a while, it's 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 of the Web Publishing Engine and transforming the resulting XML into HTML.

For more on XML export, see "FileMaker and XML," p. 641 .

For more on custom Web publishing, see Chapter 23, "Custom Web Publishing," p. 671 .

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 user's 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 user 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.

Figure 21.1. Using Instant Web Publishing, the layouts that you create in FileMaker are dynamically turned into Web pages for you.

Figure 21.2. Instant Web Publishing renders FileMaker layouts almost flawlessly as Web pages.

IWP is more, though, than simply rendering your layouts as Web pages. IWP users have much, if not all, of the same application functionality through their browsers 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

There are numerous improvements to IWP in FileMaker Pro 7. For those readers who have used IWP in previous versions, we'll 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 now has a status area that looks and functions similar 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. We'll discuss this concept more in the "Designing for IWP Deployment" section later in this chapter.

Another major difference in 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, over 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 is how it's 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 7 Advanced can also be a Web host. Not only does the latter allow greater stability and a greater number of connections, but you can also use FileMaker Server's SSL encryption capabilities to better secure your data.

Finally, the new IWP is session-based. We'll 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.

Scenarios for IWP

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

Remote Users

First, let's 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 FileMaker's 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't have any additional costs or development work. The remote users need to have a copy of the FileMaker Pro desktop application, and that's 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. Essentially, when remote users start a Citrix session, their FileMaker Pro application are running locally on the same network as FileMaker Server, and are hence very fast. All that's shipped across the network are keystrokes, mouse clicks, and screen images. Citrix/Terminal Services 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 www.citrix.com for more information on using Citrix for deploying FileMaker to remote users.

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

Instant Web Publishing offers a reasonable alternative to both FileMaker's built-in networking and to remote access emulation products as a means for providing database access for remote users. It might provide faster access to data than using FileMaker's 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, it's certainly worth trying.

Creating a Database-Driven Web Site

There are two general techniques for incorporating data from a FileMaker database into a Web site. 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't change often. For instance, you might want to publish data from an event database on your Web site. 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 Web site.

Exporting XML and transforming it into other formats via XSLT is covered in Chapter 22, "FileMaker and Web Services; see "Transforming XML," p. 646 .

The alternative to publishing "static" data is to publish data "dynamically," 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, it's 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: It's a fairly complex skill to learn and is therefore costly in terms of time and/or money.

Please see Chapter 23, "Custom Web Publishing," p. 671 , to learn more about Custom Web Publishing and how it compares to IWP.

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 Web site out of FileMaker layouts if you're so inclined. With IWP, you don't need to learn HTML or any middleware languages, and maintaining your site is as simple as editing some scripts and layouts. However, these "strengths" of IWP also become its weaknesses when 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 that's it. You can't look "under the hood" at the code and manipulate it.

Getting Started with IWP

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

The host machine ”whether running FileMaker Pro 7 or FileMaker Server 7 Advanced ”of course needs to have an Internet (or intranet) connection. Ideally, it will be a persistent connection (for example, T1, DSL), and the host machine needs to have a static IP address. If you don't 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, 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 Web site.

On Windows, users must have Internet Explorer version 6.0 (or higher). On Mac OS X 10.2.8, they'll need Internet Explorer 5.1 or 5.2. On Mac OS X 10.3, Safari 1.1 will work as well. Obviously, these options may change with new releases of browsers and new versions of operating systems, so consult the www.filemaker.com Web site 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.