Volume Number: 15 (1999)
Issue Number: 12
Column Tag: Web Development

Lasso 3.5

by William Porter, Polytrope Solutions, Houston, Texas

The leading tool for Web-publishing FileMaker databases extends its reach

Introduction

The Lasso Web Data Engine from Blue World Communications (henceforth simply "Lasso") started life several years ago as a product that made it possible to publish and manage FileMaker Pro databases on the World Wide Web. Originally, it worked only with FileMaker and only on the Mac, even after FileMaker went cross-platform three years ago.

Lasso is still the premier tool on the Mac for Web-enabling FileMaker databases, but it has expanded its reach considerably. In fall 1998, with the release of version 3, Lasso not only broke out of the Mac OS and expanded into the Windows world; it also grew beyond FileMaker, by adding support for any ODBC-compliant data source. And by enriching its tag-based programming language, LDML, Lasso matured into a tool that can do a lot more than display a product list online. It is now used increasingly to power dynamic Web sites whose HTML pages are generated from a database that the user may never even be aware of. In fact, Lasso can do a lot to enhance Web sites in which no database is involved at all.

Lasso 3.5, released in late spring 1999, is not the feature-packed breakthrough that the previous version had been. Instead, 3.5 consolidates the earlier advances (adding expanded Windows support, for example, and strengthening security), adds a handful of powerful advanced features (such as support for server-side JavaScript and XML), and expands the product line with a variety of new features, including the Lasso Developer Edition. The release of FileMaker Pro 5 almost six months later (October 1999) made it easier than ever for inexperienced users to get their data online in a hurry. Nevertheless, Lasso is not a product for Web neophytes looking for quick solutions to simple problems, and the release of FileMaker 5 is unlikely to draw a single serious developer away from Lasso.

This review article is addressed not to developers who are already using Lasso, but to users who are wondering if they should give Lasso 3.5 a try. The short answer is yes. Since I am a FileMaker developer, most of my examples refer to FileMaker Pro databases. But if you work with an ODBC-compliant data source such as Microsoft Access (Windows only) or SNAP Innovations' PrimeBase, nothing said here is irrelevant to your concerns, since Lasso's ODBC module works very much like its FileMaker Pro counterpart. (The differences are mainly terminological.) In order to tackle Lasso, you do not need to have an advanced programming background, but you should be familiar with programming or scripting concepts, and you must know HTML pretty well.

The code examples given in this article come from a simple site whose full source code can be downloaded from the Polytrope Solutions Web site: <http://www.polytrope.com/mactechreview>.

What the Heck Is It? How Does It Work?

Lasso inhabits the nebulous realm of "middleware" with competitors such as Tango, ASP and Cold Fusion.

If all you want to do is publish a fairly static product list (for example, a restaurant menu), you can format it in a word processor and print it out; to publish it online, you can pour the data into an HTML table. Browsers can interpret (and even search) HTML tables directly, without the assistance of any other software.

But static lists are worthless when the data change frequently, when the data are diverse and complicated, when you want to be able to search quickly through a lot of data, and especially when you want to really do something with the data, such as make a sale or allow users to calendar events online. (On doing the latter with Lasso, see Seth Ganahl's article in the September 1999 issue of MacTech.) Then you need a database management system (DBMS) such as FileMaker Pro or Microsoft Access, to manipulate the data. And if you want to make your database available on the Web, you will need a middleware tool such as Lasso. Neither the browser on the client machine nor the Web-server application (for example, WebTEN or WebSTAR) on the Web server can directly communicate with or manipulate the database or data source. Serving as the intermediary between the Web server application and the database is Lasso's main job. It can do several other very neat tricks, but this is its bread and butter.

Lasso is a CGI or plug-in that runs in cooperation with your Web server software. It comes in two distinct flavors: FileMaker Pro and ODBC. At the risk of stating the obvious, I will point out that, to communicate with ODBC data sources, Lasso uses ODBC. With FileMaker databases, on the other hand, Lasso can communicate in a couple different ways. On a Mac server, Lasso normally talks to FileMaker databases using Apple Events. Under Windows, Lasso communicates with the Web Companion using the FM Remote data source module, which comes with Lasso. (This can also be used on a Mac and is particularly useful if you are doing cross-platform development. The FM Remote data source module has some limitations which make it difficult or impossible to do certain things easily done with AppleEvents.) Note: FileMaker Pro 5 has just arrived with level-1 ODBC compliance, which gives read-only access to FileMaker Pro 5 (standard edition) using Lasso's ODBC module.

Developing With Lasso

Regardless of the differences in how it talks to the data source, Lasso is a remarkably consistent cross-platform tool. You can move your solutions from platform to platform with few or no changes, and it is easy to develop on one platform for deployment on the other. Lasso's only major platform drawback is that it will not work on UNIX or Linux servers.

Lasso is properly speaking not a development tool. In fact, technically, you do not need to own Lasso to develop Lasso-driven sites. (In this it is different from a product such as Tango, which requires you use its proprietary development tool.) A Lasso developer's product or output is simply a set of Web pages to which LDML (Lasso Dynamic Markup Language) code has been added.

In the past, WYSIWYG HTML editors such as Adobe GoLive and Macromedia Dreamweaver have had a tendency to munge Lasso code, so most Lasso developers have relied on text editors such as Bare Bones Software's BBEdit, to code their pages. But life is getting better for developers who would like to work in a WYSIWYG environment. Recent releases of Lasso have provided the option of coding using the "object syntax method," a slightly different way of formulating Lasso tags within angled-brackets that HTML editors find more palatable than the square brackets used frequently by LDML. And by the time this article appears in print, the Lasso Studio for Dreamweaver will have been released. This promises to be a major benefit to developers, who up until now have suffered from an occupational hazard that I call the "Lasso headache," brought on as a result of the intense concentration required to find and understand Lasso code that is floating here and there in a sea of HTML that may be quite complex.

While you can write Lasso code for free, you can't test it. To test your Lasso solutions effectively, your development environment must include (1) Web server software, (2) the Lasso Web Data Engine, cooperating with the Web server software as a CGI or plug-in, (3) the DBMS that runs your databases, such as FileMaker Pro. Finally, (4) you will need to use a browser such as Netscape to view the site you have created.

How many physical machines your development environment uses is up to you. Lasso must be installed on the Web server, but you could put the databases on a second machine (for example, one running FileMaker Server) and run your tests from a browser on a third machine. What most developers do, however, is use a single machine, which acts as both server and client. The Lasso Developer Edition, a package introduced with the release of Lasso 3.5, provides all the Lasso data source modules, in case you already have a Web server to work with; and if you don't, the Developer Edition also provides a special limited-access version of the Lasso Web Server. The Developer Edition version of the Lasso Server limits you to two concurrent connections to the database, but this is enough for you to develop and test on your own machine and to enable your client to access your development server over the Internet and view the site's progress. (The unlimited-access version of the Lasso Web Server, available only for the Mac OS, while not nearly as multi-faceted an application as WebSTAR, is an economical and reasonable choice if you will only be serving HTML and Lasso pages.)

The single biggest problem for new Lasso developers is figuring Lasso out sufficiently to get that first site finished. Blue World provides no step-by-step tutorial that takes you by the hand through the process of installation and into development, and the Reference Manual, while thorough, is addressed more to experienced developers than to beginners. On the other hand, one of the greatest things about Lasso is that it is possible for a developer to learn a little bit and do something with it, where with many of the alternatives such Microsoft's ASP (Active Server Pages), you have to learn quite a lot before you can do anything at all.

Lasso Performance

FileMaker 5 Unlimited adds a couple nice features to the Web awareness built into FileMaker 4.x, such as the ability to display your FileMaker layouts on the Web directly using XML, and support for distributed database serving. Nevertheless, Lasso remains the tool of choice for building Web applications around FileMaker databases, for two reasons: first, because as a programming tool, LDML eats CDML's lunch; and second, because Lasso is multi-threaded and FileMaker 5 (alas) is not.

A Lasso-driven site allocates the different tasks to different applications: the Web server serves up HTML page, Lasso talks to the database, and the DMBS responds to Lasso's requests. While the Web server serves pages and FileMaker is processing a single request, Lasso may be very busy. Its right hand processes and queues up requests to be sent to the database, while its left hand converts data received from FileMaker into HTML pages formatted on the fly, and sends those DHTML pages back to the server. FileMaker may ultimately be the boss, but Lasso is a dream administrative assistant, getting everything as ready as possible before putting it on the boss's desk. A site run by the Web Companion alone, on the other hand, is like an office in which the boss has no secretary. He has to answer his own phone, type his own letters, and do his own photocopying - and he can only do one thing at a time.

I hasten to mention that people who only think of Lasso as a tool for serving up FileMaker databases tend to think that Lasso is only appropriate to sites with no more than moderately heavy traffic. This is not the case. The bottleneck is FileMaker, not Lasso. On a fast server, accessing a multi-threaded ODBC data source, Lasso is capable of handling heavy traffic gracefully. (A white paper comparing Lasso to ASP was prepared by ASP develper Josh Hoover and published in October; it can be downloaded from Blue World's Web site. The gist of the report is that Lasso runs faster for most tasks, uses fewer lines of code to get the job done, has the advantage over ASP in flexibility and extensibility, is easier to get into, and is considerably more secure.) Real statistics are hard to come by, and there are other factors to consider as well, but such a site could probably deal with hundreds of thousands of Lasso/database requests a day. In other words, Lasso is a serious commercial-grade tool.

Example Problem: An Online Student Directory

You have been asked to put online an elementary school's student directory. The school accesses this directory internally over its LAN, and the records for students will be created by school staff. Over the Web, the school would like parents or students to be able to update (but not create or delete) their child's record. Passwords will be mailed to parents for this purpose; only someone who knows the "password" associated with a record will be able to edit it. Parents should also be able to control whether their child's record is viewed online, and if it is, how much of the data is public. What is involved in building the site?

Notice first that some of the things that the school wants will be done best in the database. The first step to building a good Lasso site is knowledge of the database system you are dealing with. Each record in this database needs to have a field makepublic which, if checked, indicates that the record may be published online. Additionally, every significant data field such as phone must be complemented by two other fields, a permissions field (phonepublic) and a calculation field (phonecalc). Using FileMaker, the formula for the field phonecalc would be:

	If (phonepublic = "y", phone, "")

Good database design is an important part of the Web-publishing process for other reasons. In theory, Lasso can take just about any database that works and publish it on the Web. But in practice, the KISS principle applies here in spades. Simple, efficient database design will make your site run more quickly and more reliably.

Okay, so you have finished writing the database (directory.fp3). You have the Lasso Developer Edition installed on your own computer and properly configured, and with your DSL connection, you have a relatively stable IP address that you can connect to from the copy of Netscape that you use on that same machine. FileMaker is running the database in the background. You are now ready to write the pages that will make up this simple site. We are going to use five pages, as shown in Figure 1. (This site structure is not only simpler than the one I would use in reality, it also possesses some security problems that we will look at.)

The starting page

The starting or home page has two single-field search forms on it. One field can be used by anyone, to search for students by name or year of graduation. This is the form one child will use to find another's phone number. The other form has only one search field, which allows students (or their parents) to search for their own records only, by password. The password is actually nothing more than a unique string entered in a field called password in each record. If properly coded, this search will result in (at most) one record being found, the record that the user is authorized to edit.

The public student list

If the public-access search produces results, this page will display them, in a list. Typically, hit lists of this type are formatted as HTML tables, one row of which is marked for use over and over again as many times as needed to accommodate the number of records found. In addition, this list might display some simple information such as each student's first name, class rank, and telephone number (provided that these fields have been marked to permit display). Finally, each student's name will be formatted as an href link containing a bit of Lasso code, so that if the user click's on that student's name, the browser will load the detail page for that student's record.

The public detail page

This page will display for a single student record all the data that have been marked for public display.

The private update page

This is simply a form showing all the data-entry fields for a student's own record, with the current values inserted into editable text fields. When the submit button is clicked, any changes made by the user will be made in the database, and the user will be taken to the detail page. It is not necessary to worry about whether data is authorized for publication or not on this page, because the student is viewing his own data. Other than the owner of the record, only the school staff, who access this database via their internal LAN, are able to view all of this data. But they are viewing the database directly in FileMaker Pro, not in browsers on an intranet.

The no-records-found page

This page will be seen only if a search finds no results. It contains a simple statement advising the user that no records were found matching the search criteria entered and giving the user the chance to go back and try the search again, or go somewhere else.

Two Different Ways to Code These Pages

Lasso offers the developer two completely different ways to code pages: using the traditional tags or using inlines. Because the traditional tags resemble HTML in form and function and require less thought to use then inlines, developers learning Lasso are tempted to rely upon them exclusively. But they pose a variety of security risks to your Web site. Although traditional tags and inlines can be mixed, most serious developers use the inline tag almost exclusively, in large part because it is more secure.

Traditional Lasso tags

Originally, Lasso pages relied a great deal on ordinary HTML. For example, the form on the first page of this site (studentdirectory.html) which you would use to find other students by last name might be coded like this:

<form action="action.lasso" method="Post">
<input type="hidden" name="-database"
	value="directory.fp3">
<input type="hidden" name="-layout" value="search">
<input type="hidden" name="-response" 
	value="list.html">
<input type="hidden" name="-noresultserror" 
	value="nothingfound.html">
<input type="hidden" name="makepublic" value="yes">
<input type="hidden" name="-sortfield" value="lastName">

<p>Enter the last name and/or graduating year of the 
student you wish to find:</p>
<p><input type="text" name="lastName" value="" 
size="25"></p>
<p><input type="text" name="class" value="" size="10"></p>

<input type="submit" name="-Search" value="Search">
</form>

This code is just standard HTML with Lasso specified as the CGI ("action = action.lasso"). It gets the job done. It tells Lasso what do do - what database to search and on what layout to look for the fields to search in, what file to use to format the results, and so on. Note that it also adds a search criterion here: the value in the field makepublic must = "yes."

But there is a significant problem with this form. It gives everything away. Any curious user can view this information by using his browser's View Source command. A clever student - especially one who knows just a little about Lasso or CDML (since this is also how the CDML works in the Web Companion) - may be able to glean from these clues enough information to hack into the database. With this sort of information, for example, a student could create a CGI search string, designed to find another student, for example:

action.lasso?
	-database=directory.fp3&
	-layout=search&
	-response=list.html&
	-makepublic=no&
	-findall

If the hacker typed this code into the browser's location field (run together on the same line), then hit Return, he would be rewarded with a list of all of the records to which public access was supposed to be denied. And the link to the detail page from these records would show him any details that the parents, thinking the entire record was off-limits, had not bothered to deny access to. With a little more ingenuity, the hacker could possibly gain access to the update page and actually modify the data in a record that he was not even supposed to be able to view.

Now you can take some comfort in the fact that what a hacker can do is limited by the permissions given to all users in Lasso security, which we will discuss in a minute. If all users are not by default not allowed to delete records, then even a properly formulated string commanding Lasso to delete a certain record will fail to be executed. But our example site does allow users by default to update records, and it relies upon the design of the site to restrict users to viewing only records which the record owner has permitted to be viewed, and to updating, that is, editing, their own records. As we have seen, this reliance is ill-advised.

Inlines: The better way

Security is always a multidimensional task. Server security, Lasso security, and good site design all play a part. But as we have just seen, it does no good to lock the door if you leave the key in it, on the outside! One of the most important things you can do to keep your site and your data secure is to code this site entirely differently, using Lasso's more secure inline tags. Actually, besides being more secure, inlines have many other advantages over traditional tags. To take full advantage of inlines, it is necessary to learn about some of Lasso's other tags, such as token and form_param, both of which allow form parameters to be passed from one Web page to the next as if they were stored in short-lived variables.

The secret of the inline lies not in its syntax, which is not all that different from the syntax of the traditional tags - just different enough, many Lasso users would say, to be annoying! But while traditional tags were stored in one page (the pre-Lasso page) and the results they generated showed up in another page (the post-Lasso page), inlines are stored in the very file that will be used to package the results of the action or actions that they specify. When a page contains inlines, it typically is saved with the filename suffix .lasso, which tells the Web server to hand processing of the page to Lasso first. (This is not strictly necessary. You could configure your Web server's file-suffix settings so that the Web server would also hand .htm or .html pages to Lasso first, but this would mean that Lasso would be asked to look at a lot of pages that had no Lasso code in them at all.)

Let's look back at the coding of the search on the first page of our site for students by name or class. We can't get around the need to create a form on the main page. After all, the user has to have a field in which to type the name of the student he wishes to find. But the form can be coded so that it reveals very little information about the database, like this:

<form action="list.lasso" method="post">
<p>Enter the name and/or graduating year of the student you
		wish to find:</p>
<p><input type="text" name="1" value="" size="25"></p>
<p><input type="text" name="2" value="" size="10"></p>
<input type="submit" NAME="-nothing" VALUE="Search">
</form>

Here, the HTML source code reveals nothing about the database at all. Even the names of the fields being searched are disguised as arbitrary and meaningless numbers. This form does not even trigger a search. It does only two things: it captures the data typed into the form fields and stores it as form parameters named "1" and "2," and it hands these form parameters to the file list.lasso, which is specified as the action parameter for the form.

The following code is placed on the response page (list.lasso):

[inline: database='directory.fp3', layout='search', 
'makepublic'='yes', 'studentname' = (form_param: '1'), 
'class' = (form_param: '2'), sortfield='lastname',
noresultserror='nothingfound.html', search]
<-!The data-display part of the page goes here->
[/inline]

The search string(s) entered by the user are passed to this inline as form parameter values with the names '1' and '2'. This inline command tells Lasso everything that the traditional form code used earlier told it, but this time it tells Lasso only. The instruction in the inline is processed by Lasso, and once processed, it disappears. It will not be passed to the browser, not even as source code. The user will see only the results - a list of students - not the code used to produce those results.

The student list

Now let's add the code necessary to display the list of students found by the search. Even if the user searches by last name, more than one record may be retrieved, and of course, if the user searches by graduating class alone, a large number of records will be returned. So it makes sense initially to display the records found in a list. The code for the list is usually placed inside an HTML table. One row of the table gives column (field) titles. Another row is marked with the Lasso [records] tag, which tells Lasso to reuse the formatting in this row as many times as necessary. The table looks like this:

<table>
<tr><td>Name</td><td>Class</td><td>phone</td></tr>
[records]
<tr><td>[field: 'studentname']</td>
<td>[field: 'classcalc']</td>
<td>[field: 'phonecalc']</td></tr>
[/records]
</table>

If Lasso finds at least one student whose last name is "Roosevelt," it will fetch the data for each student's record from the three fields specified in the table (studentname, class and phone), and will substitute the data for the Lasso field tags shown above. The user will see a nicely formatted list of students named Roosevelt, and if the user invokes the browser's Show Source command, instead of seeing the code above, he will see something like this:

<tr>
<td>Franklin ROOSEVELT</td>
<td>2002</td>
<td>713-444-1945</td>
</tr>

Lasso has generated the actual HTML for the page on the fly, by packaging the data found in the manner directed by the response page.

A weakness of inlines

What is missing from the code above is a way to get from the list, which displays only a little bit of information about the student, to the full details for that student. Lasso 3.5 only provides one easy way to do that, using a detail link. Here is the previous code with the detail link added:

<td><A HREF="[Link_Detail: Layout='detail',
Response='detail.html']">
[Field: 'namefirst'] [field: 'namelast']</A></td>

This says that, if someone clicks on a given student's name in the list, Lasso should refer to the database layout named detail and load the page "detail.html." But there is a problem here, once again. The Lasso tag [link_detail] is processed and converted into a standard href link by Lasso, so when this page is served up to the user and the user looks at the source code, he will see something like this:

<td><A HREF="list.lasso?-database=directory.fp3
&-layout=detail&-response=detail.html&-recID=5
&-search">[Field: 'namefirst'] [field: 'namelast']</A></td>

In other words, everything we tried so hard to keep hidden earlier is being revealed anyway. I can hear you saying already, "So use an inline!" Good. You are catching on. Unfortunately, in this case, there is no ready alternative. Inlines are still somewhat new, and Blue World has not yet had a chance to do a comprehensive overhaul of the Lasso tag library to make it easy to do everything in inlines. The only thing you can do is a sort of workaround. It's not in the documentation-which in fact never discusses the differences between the traditional Lasso tags and inlines-and it's hardly obvious, especially to beginners. Here it is. On the student list page, the code above would be replaced by this code:

<td><a href="detail.lasso?-token.ID=[field: 'ID']&-nothing"> [field: 'studentname']</A></td>

The name of the response page (now "detail.lasso") has to be revealed, and the value in the ID field will also be revealed, so it is a good idea to keep it meaningless. But there isn't much that even a clever hacker can do with that little. Notice here that the Lasso action -nothing is used, because the href tag itself is not really doing anything except creating the token and calling the response page.

The rest of the work is done in the response page, which looks like this. This time we will look at the HTML for the entire page.

[inline: database='directory.fp3', layout='detail', 'ID'=(token_value: 'ID'), search]
<HTML>
<HEAD>
	<TITLE>Detail</TITLE>
</HEAD>
<BODY>
	<p>[field: 'studentname']</p>
	<p>[field: 'streetcalc']</p>
	<p>[field: 'city'], [field: 'state']</p>
	<p>[field: 'phonecalc']</p>
	<p>[field: 'classcalc']</p>
</BODY>
</HTML>
[/inline]

The inline searches in the ID field for the value passed by the token, then creates the HTML page that displays it. Ultimately no information is revealed about the database at all.

As for the update page, it may be enough here for me to comment that it is basically an HTML, but its fields have been populated with data from the record found when the user searched for their password. The fields in the code for the form are given non-revealing string identifiers once again, e.g.,

<input type="text" name="1" value="[field: 'namelast']">

When the user clicks on the Update button on the form, the form parameters are captured, the page detail.lasso is called, and an inline in that file does the actual processing of the update.

Other strengths of inlines

I mentioned earlier that inlines have other advantages besides being more secure than traditional tags. They can, for example, be nested within one another, meaning that you can ask Lasso to perform more than one action or reference more than one database on the same page - something not possible with the Web Companion. Using nested inlines you can actually achieve results that look like they derive from relationships in the databases, even if no such relationships exist. There is almost nothing that Lasso can do that cannot be done with inlines, and there isn't much that inlines cannot do.

Perhaps because Blue World does not want to suggest to users who built sites in Lasso prior to the introduction of inlines last year that their sites are not secure, the Lasso documentation nowhere expresses a preference for the inline over the traditional tags. It should. If you decide to learn to develop with Lasso, ignore the traditional tags and learn how to code your site entirely with inlines right from the start.

Going Beyond the Conventional Online Database

When they think of Web-enabled databases, most users think of conventional lists of data that have simply been made available online: library catalogues, product and pricing lists, school registration systems, calendars of upcoming events, and the like. But as a Web-programming language, Lasso is so flexible and so powerful that it can be used to build truly dynamic Web sites, sites in which the database is not a part but the whole.

One of my own early Lasso projects involved converting a static site for the stables where my daughter rides http://www.hermannparkstables.com to a more dynamic database-driven site. The site serves a variety of informational purposes, but mostly, it's a newsletter for the stables, announcing upcoming events, or reporting on the results of recent horse shows, births at the stables, and so on. A simple flat-file database stores reference information on the articles, including article title and date, and the pathname on the server to the include file that contains the actual article. A Lasso include file is nothing more than a text file, usually a snippet of HTML, that is inserted into the shell for a web page provided by some other HTML file. I chose to use includes, rather than simply serve up text from a field in the data, because includes allow me to format the articles more fully-to create a table to report riders' results from a show in one article, or to add href links to another, and graphics to a third. The main page of the site automatically displays the latest news article available, which means that it is not necessary to do the cutting and pasting that we used to do. And because the site is built around a database, it is very easy to update (I don't have to create an actual new HTML page) and past articles are archived and searchable.

So far this is trivially simple. The next step in this slow-moving project will be to add a couple of databases that make personalization of the site possible. For example, we would like to add a couple databases to the site: one for horses (with pictures, of course, which Lasso can handle nicely), and one for upcoming events. Visitors to the site would be encouraged to define their preferences: Who is your favorite horse? What sort of upcoming events are you particularly interested in? This is simply a more modest version of personalized portals such as My Yahoo! The preferences could be stored in a cookie set on the client machine. Such a site requires some fairly intelligent coding (and a little more time than I have had to volunteer), but Lasso is more than up to the task.

In fact, Lasso can do a lot to enhance a site that does not involve any database whatever. Another client, a firm that processes health-care claims, wanted their own clients to be able to submit information to them using a Web form. The information, after being submitted on the Web, gets mailed to my client's office. But after the user clicks on the submit button and before the information gets emailed, Lasso massages the data in some ways that make it much more useful to my client. Using Lasso, I was able to get the job done quickly and in a way that is completely reliable. And this does not begin to push Lasso to its limits. Lasso's support for advanced technologies such as XML, server-side JavaScript and Java, and its ability to work not just with FileMaker Pro but with any ODBC-compliant data source, mean that Lasso is much of an application-development tool than the product name "Web Data Engine" seems to suggest.

Lasso Security

Once configured properly, Lasso security is very robust. But it can be a pain in the neck to set up, partly because the Web interface used for configuring Lasso is confusing, and partly because the Lasso documentation is sketchy and confusing.

The screen shot here gives a pretty good idea of what Lasso's security configuration pages are like. What, one wonders, is the difference between the two links at the bottom of the page, "Lasso Security" and "Security Settings"? No way to find out but to click on the links and see (and even then the difference won't be clear at first). Elsewhere, the configuration pages lead you down dead-ends, forcing you to hit the back button to escape. The same sort of confusion can be found in chapter 13 of the Reference manual, which deals with security, for example, "The Lasso security default page is divided into four sections: Database Administration, Add New Database, Users Administration and Global Administration." The beginner may wonder why adding a new database does not fall under the heading of "database administration."

Configuring Lasso security is first a matter of determining what you will allow "all users" (meaning anyone) to do with "all databases." One expects this to be a default, but it is not. Rather, it is an irrevocable minimum. Say you use the setting shown in Figure 2, which gives all users permission to search databases. You will not be able to override or eliminate that privilege with a particular database. The only thing you can do for specific databases is give specific users additional privileges. If security is a concern for you or your client at all, there are likely to be databases that you do not want to let people even search. This means that the only really good way to configure Lasso security is to give all users no privileges whatever, then to assign specific privileges to individual users, one database at a time.

And there is an odd security risk with the standard installation of Lasso. By default, Lasso installs its configuration files in a folder at the domain's root. This means that typically, anybody with a browser and Web access can get to your Lasso configuration pages by going to <http://www.yourserver.com/lasso>. There, they can use the Instant Web Publishing feature to view the names of all of the databases that Lasso can talk to. And from there, if all users have been granted "search" access (the factory default), these very nosey people may be able to use Instant Web Publishing to peruse the data in the personnel database that nobody expects you to have access at all. The solution is simple: move the folder named "InstantPublishing" out of the Lasso folder. One hopes that the next release of Lasso closes this security hole.

These quirks aside, Lasso security is tight and firm, and complements your Web server's security settings intelligently. You can lock your data down pretty well, by controlling users, and by limiting access to specific databases and to specific fields, even to specific directories on the server.

Dealing with Errors (Including Your Own)

Lasso development tends to involve a lot of trial and error, for experienced users as well as beginners. Lasso is not C++ and can be learned, if not mastered, by a determined newcomer within a relatively short time. But, the development of your first site or two will almost certainly involve some frustration. Even if the documentation were better, it would still be a challenge sometimes to track down the source of a problem, because it can lie in so many places: server problems, Lasso coding problems, HTML faults, FileMaker problems, and so on. Fortunately, the new tag parser and the debug module, new in Lasso 3.5, give you feedback that goes beyond an error code.

Most beginners make the same mistakes: Lasso is not properly installed or configured; LDML code contains typos; the LDML code refers to databases or layouts or fields inaccurately; or the user has inserted LDML code into faulty HTML. These mistakes are sure-fire Lasso busters. Blue World provides a free thirty-day demo of Lasso, and goes on to provide thirty days of support after your purchase the product. Be sure to download and begin with the demo before you buy. You will want to get into the product as far as you can before you buy, so that you make the best use of your month of support.

As you move beyond the basics, you will want to take advantage of Lasso's good error-trapping capability. Well-built Lasso sites tell users when they have failed to include required data in a form; when no records matching the search criteria were found; when a password is invalid; and when the user lacks the necessary level of access to the database or a layout or a field.

Miscellaneous Features

My aim in this article has been to provide an introduction to Lasso, and there are necessarily a large number of intermediate and advanced topics that must be left for you to investigate on your own. These include Lasso's e-mail capability; its amazingly simple credit card validation tag; its rich set of tags for manipulating text strings, dates and numeric values; its file management tags, which allow you to create, write to, delete, move and rename files on the server; the ability to create Lasso macros (routines that perform a task and can be stored in one place and referenced repeatedly); improved support for languages other than English, with the addition of new encoding tags; support for server-side JavaScript and XML; and for advanced developers, the Lasso Java API (LJAPI), which allows Java programmers to extend Lasso's capabilities on the server side.

Conclusion

Lasso 3.5 is a flexible and powerful tool that many developers of Web applications would find a useful addition to their tool box. Once you get over the initial learning bump, Lasso sites can be produced relatively quickly, and Lasso's support for both Windows and Mac OS, and its ability to work with any ODBC-compliant data source, make it an ideal tool for prototyping large sites, or for building medium-sized sites today with an eye toward growth in the future.

Useful Resources

There are at present no books on Lasso available. The best place to go for more information about Lasso is to the Blue World Communications Web site and to the Lasso Solutions page in particular:

<http://www.blueworld.com/blueworld/products/lassosolutions.html>. You will also find on Blue World's site information on how to subscribe to the Lasso-Talk list, an indispensable support group for Lasso developers. Beginners should find it helpful to visit my Learning Lasso site: <http://www.polytrope.com/learninglasso>. For an excellent overview of the subject of databases on the Web which refers to a number of the alternatives to Lasso, see Jesse Feiler's Database-Driven Web Sites (San Francisco: Morgan Kaufmann Publishers, Inc., 1999).

William Porter is the owner of Polytrope Solutions, a firm in Houston, Texas, specializing in custom database and Web-applications development using FileMaker Pro and Lasso. A member of the XXII Group, an international consortium of Web developers, Will is currently working on a site designed to help new users of Lasso over the initial learning bump: http://www.polytrope.com/learninglasso. You can reach him by sending e-mail to will@polytrope.com.