by Marie P. Folker, <editor@filemakermagazine.com>, http://www.filemakermagazine.com/
The Lasso Way
BONUS: REGISTRY.FP3 and HTML files
PLATFORM: Mac/Win
Blueworld Communications' Lasso has been bridging the gap between FileMaker Pro databases and Web browsers for many years now. In fact, Lasso 1.x technology was purchase by Claris and built into the Web Companion with only minor changes. The purpose of this article and the accompanying bonus solution is to demonstrate how closely knit these two CGIs really are. For those developers who are starting to feel a little confined in the limited tag library of CDML, this comparison should sweep away any reservations of switching to Lasso over Web Companion.
The Caveat
As we have discussed in earlier articles about Lasso, there is one major caveat. You have to be running a MacOS Web server and probably Webstar. While there is a server version of the Lasso CGI, we'll be looking at the plug-in for Webstar by Starnine Technologies. Those left high and dry with Windows based Web servers will have to stick with Web Companion for the time being.
The Bonus Solution
If you do not already have Lasso compatible hardware and software, don't fret. This article will detail some of the minor differences between this language and CDML. The model we're using is the add record model that first appeared in the "CDML 101 / The Add Form" article from issue 26.
Different CGI, Different Form Action
The form action is an attribute that resides in the open form tag. In our CDML environment, it has been alerting Web Companion that it will be handling the communication between the browser and the FileMaker Pro database. With a new CGI comes a new call; let's look at the following code:
<FORM action="action.lasso">
<INPUT TYPE="hidden" name="-database" value="REGISTRY.FP3">
<INPUT TYPE="hidden" name="-layout" value="cgi">
<INPUT TYPE="hidden" name="-response" value="thanks.htm">
The CGI call is "action.lasso" instead of "FMPro". Not a big deal, makes sense really, and the nice part is that this construct is an HTML standard. The open form tag is followed by the call to the CGI of choice. Here is what an embedded link would look like in LDML rather than CDML:
<a href="action.lasso?-response=form.htm">View Solution</a>
Looking further into this sample form code, also notice that the three hidden input types are familiar to those written in CDML, just the vocabulary has changed.
CDML LDML
-db = -database
-lay = -layout
-format = -response
The first action in our bonus solution is an embedded link that renders the top.htm and bottom.htm include files around our registry form. As you know, we have to include the CGI in requesting the form.htm page so that the include tags get replaced with the appropriate.txt files. Let's again look at the embedded link code:
<a href="action.lasso?-response=form.htm">View Solution</a>
Following the form action, we see -response=form.htm. -response is the same thing as -format in CDML. The major difference in this link and a CDML one is the lack of an action. Remember that in CDML, if we want to interact with the CGI and not the database, we append the -view action tag to the end of the string. LDML has a similar tag to the -view tag, only they have named it -nothing. Makes sense, we want nothing to happen with the database in the background. The key difference here is that in LDML, if you do not specify an action tag, then "-nothing" is implied and does not need to be specified. Pretty clean.
The Form
The form.htm page has a number of text input types to be filled in and a submit button to pass the information on to the CGI. Since we have already looked at the form tags and hidden input types, let's next examine the visible input types.
<INPUT TYPE="text" SIZE=50 name="first_name"><BR><BR>
<INPUT TYPE="text" SIZE=50 name="last_name">
Notice that there is absolutely no difference in the way these input types are constructed. The most important thing to remember here is to reference the field names exactly as they appear in Define Fields of the database.
There is a minor difference in the submit button code, but only in terms of vocabulary. It was decided by the developers at Claris/FileMaker Inc. that actual FileMaker Pro terminology be used whenever possible. Here is what the LDML submit button looks like:
<INPUT TYPE="submit" NAME="-add" VALUE="Submit">
Notice that instead of -new to create a new record, LDML uses the -add tag. This tag works exactly as -new, just a name change. Here is a table that lists the CDML and LDML action tags equivalents:
CDML LDML
-Delete = -delete
-Dup = -duplicate
-Edit = -update
-Find = -search
-FindAll = -findall
-FindAny = -random
-Img = -image
-New = -add
-View = -nothing
Notice that in some cases, the tags are the same and when they are different, they are at least descriptive in nature and are easily referenced in the LDML reference database that accompanies the Lasso product.
The Confirmation Page
The thanks.htm page contains field replacement tags that differ slightly from the CDML construct. Consider the following code excerpt:
Thank you, [field: full_name], for taking the time to fill out our survey.
The field tag doesn't start with [FMP-. Instead, a field is referred to as [field: field_name]. This is a cleaner way to code. Less typing is always welcome. In fact, nearly everywhere you see a tag starting with [FMP- in CDML, there is a shorter and descriptive naming convention.
In The End
If you have the capability of running Lasso instead of Web Companion, it is well worth considering. Not only will you find that you already know more about this language than you thought, you will have access to a leading edge array of tags and tricks that has gone through two major feature revisions since the release of Web Companion. To put it another way, there are things that can be accomplished with Lasso that cannot be done with CDML. With LDML sporting over 50 more tags than CDML, there is no wonder why. In future articles, we'll explore some of the unique differences of LDML that set it apart from it's CDML spinoff.
## END ##