Lasso (programming language)
From Seo Wiki - Search Engine Optimization and Programming Languages
|Stable release||8.5.6 / May 1, 2009|
|Operating system||Mac, Windows, Linux|
|Type||Middleware & Application Server|
Lasso Professional combines an interpreted programming language and server for developing internet applications which use web browsers for the client user interface to connect to HTTP and database servers. Lasso is developed by LassoSoft, LLC.
Lasso provides administration management over Lasso (via its internal users and groups) to control explicit access permissions-based to data sources and language features to improve security and data integrity in a multi-author web application development environment. Lasso Server provides access to MySQL and numerous other databases via JDBC and ODBC, as well as FileMaker Pro. Lasso Server runs on Mac OS X, Windows 2000, Windows 2003 and Red Hat Linux.
Lasso's language, Lasso Dynamic Markup Language (LDML), can be written in a square bracket tag format which resembles HTML, or in a LassoScript format similar to many other scripting languages such as PHP, Perl, and Python. LDML can be written with procedural or object oriented techniques and structures, and supports numerous data types including arrays (indexed lists) and maps (name referenced lists).
Lasso is an extendable language. It currently includes the ImageMagick suite of image manipulation tools, the ability to generate PDF documents and process and send email. Lasso also includes broad support for industry standards such as XML, SOAP, WSDL, JSON, Java EE, and Java Beans. Developers can extend Lasso by writing their own custom routines which can be used and reused as custom tags or create new functionality via Java or the C programming language to suit their needs.
Data Source Abstraction
The Lasso programming language provides developers the ability to create dynamic web sites or applications with data source abstraction. The Lasso language allows the developer to program in such a manner as to be independent of coding for a specific data source. This allows files, sites and applications created with the Lasso language to be ported from data source to data source with minimal or no changes. This level of abstraction is achieved by the interpretive nature of the language.
Developers configure data sources within the Lasso administration system, setting permissions, connection parameters and other relevant settings. They may also set an alias for the data source, which allows for the abstraction.
Example 1 - Transitioning Data Sources
The data source for www.foo.com is the FileMaker database foo_facts.
Within the Lasso administration system, the developer creates the alias name info for the foo_facts database. Within the developer's Lasso code, the call for data is made to 'info' using the Lasso data manipulation tags.
Lasso receives the call to 'info' as an instruction to retrieve data from the foo_facts database and generates a valid FileMaker request. The data is returned and is presented to the end user per the developer's code. At a later date, the administrators of the www.foo.com website choose to switch a MySQL database.
To accommodate this transition, the developer modifies the Lasso administration system by pointing the alias 'info' to the new MySQL database. If it is given that all of the Lasso programmed pages used the Lasso language exclusively (no proprietary tags or functions), then no further adjustments are required. Lasso now interprets calls to 'info' as requests for data from the MySQL database and casts the requests as MySQL statements.
Example 2 - Portability
A developer maintains local and remote copies of the same data source. The local data source is labeled dev_foo. The remote data source is labeled foo. In the Lasso administration system on both the local and remote servers the data source is known by the alias info. The developer calls the data source info within the code on the Lasso pages. The Lasso server interprets the call to info based on the settings with in the Lasso administration system. Pages created by the developer, therefore, can be moved between the local and remote servers without need for server-specific coding and the developer is able to maintain independent local and remote data sources, ensuring data fidelity and security.
The Lasso programming language provides a multi-layer security approach. This allows developers to set security parameters via a broad range of factors.
- Database Security
- File Security
- Access Security
- Session Security
Please refer to the LassoSoft website for a further description of the Lasso security system.
Here are three ways to say "Hello world!" on a Lasso page. The last one is of course the easiest.
<?LassoScript 'Hello World!'; '<br>'; ?> ['Hello world!'] Hello world!<br>
Square brackets are reserved in Lasso, so you have to use html entities if you want to use square brackets on Lasso pages for other purposes than marking Lasso tags. Alternately, you can print square brackets using Lasso itself.
[ // this example begins with the LassoScript syntax // here we do a database search inline( -search, -database='db_name', -table='table_name', 'field_name1'='searchvalue', -sortfield='field_name2'); Records; // this marks beginning of a loop through found records Field('field_name2'); '<br>'; // here a db field was shown // next we build a web link using field values // many like to use the square bracket syntax for that kind // of thing, so we break the LassoScript ] <A HREF="mypage.html?e1=[Field('e1')]&e2=[Field('e2')]">Go for it!</A> <br> [ // LassoScript syntax again; we only have to close the // so-called "container tags" (records, inline) that are still open /Records; /inline; ]
Inlines are the basic Lasso tool for database actions, though they are sometimes also used to set a temporary username and password. Database commands can be issued as above, in Lasso's db-independent metalanguage, in which case the same search code works for MySQL, FileMaker Pro or for any other database backend with which Lasso can connect. This greatly enhances the portability of Lasso solutions. If needed, a SQL statement can of course be embedded in the inline, when using a database server that supports SQL.
Lasso language is not case-sensitive. Thus "db_name" and "DB_Name" mean the same thing. Note that in the above example, the dashes (-) before commands mark subtags, which are only present inside the primary tag (in this case the inline).
The values carried by the www link in the above example would be captured on the result page using action_param tag. Typically, action_params are there converted to variables:
<?LassoScript var( 'e1' = action_param('e1'), 'e2' = action_param('e2'), 'e3' = action_param('e3') ); ?>
This is advisable, because variables, unlike action_params, can be trusted to work all the way to the end of the page.
99 Bottles of Beer
The next example prints out the lyrics for the song "99 Bottles of Beer".
[ // first we define a couple of variables Variable:'lb' = '<br />\r'; // XHTML line break and a return (saves typing) // do we need plural? Variable:'plural' = ''; // this is a string type variable // that variable will be reset for each loop_count (see inside the loop) Loop:-LoopFrom=99,-LoopTo=1,-LoopIncrement=-1; /* this loop will count *down* Loop_Count is a counter that is created and updated automatically. It's a good habit to frame it with (parentheses), though that's not really necessary */ If: (Loop_Count) > 1; $plural = 's'; Else; $plural = ''; /If; /* now let's print the lyrics to the screen the "addition" below actually concatenates strings, if one or more of the constituents is a string instead of integer etc. */ (Loop_Count) + ' bottle' + $plural + ' of beer on the wall,' + $lb; // actually it's easier without the + signs: (Loop_Count); ' bottle'; $plural; ' of beer.'; $lb; 'Take one down, pass it around,'; $lb; If: (Loop_Count) > 1; (Loop_Count) - 1; // these are both integers, so they will be subtracted Else; 'No more'; /If; ' bottle'; If: (Loop_Count) != 2; 's'; /If; ' of beer on the wall'; $lb; $lb; /Loop; 'Go to the store,'; $lb; 'buy some more,'; $lb; '99 bottles of beer on the wall!'; ]
(From Vince Bonfanti, Lasso's 1st father - edited for content)
In the Fall of 1995 I was trying to publish a FileMaker Pro database on the web for the company I was working for. There were two solutions available at the time, Eric Bickford's WEB-FM, And Russell Owens' FileMaker CGI (ROFM)
Both of these were implemented using AppleScript (WEB-FM was subsequently rewritten in C), and were therefore painfully slow (at least for the application I was developing). Both also required use of FMP calculation fields for formatting, which I found tedious and error-prone. In order to overcome these limitations I decided to write my own CGI, using C/C++ so it would be fast, and using the notion of HTML-based "templates" instead of relying on calculation fields. That CGI eventually became Lasso 1.0.
Lasso 1.0 probably owes more of a debt technically to ROFM than WEB-FM. For example, the notion of passing commands to the Lasso via URL/Form parameters was taken directly from ROFM (in retrospect, using the "inline" tag is probably a better idea). Also, I had never worked with FileMaker via AppleScript prior to this effort, so having the AppleScript source code for ROFM to learn from was invaluable. - quoted from Vince Bonfanti. Courtesy LassoSoft, LLC via ListSearch.
Blue World Communications, Inc., owned by Bill Doerrfeld, was a small print advertisement and web development company working out of Bill’s basement in Issaquah, Washington when they first released Vince Bonfanti's work as Lasso and LassoLite 1.0 CGI.
Because of its simple set up, easy learning curve, and clear speed advantage, Lasso’s market share quickly overtook its competition. At this point Lasso only worked with FileMaker Pro 3.x and WebSTAR, and only ran on Apple Macintosh OS 8 and above.
Lasso's popularity grew most notably from Blue World’s acquisition of, hosting of, and frequent participation in, many email discussion lists, many of which specifically pertained to FileMaker Pro. This helped brand the company's position in the market place, while at the same time placed Lasso in developers minds as a way to web-enable FileMaker Pro. Blue World also strongly positioned itself at MacWorld conferences. It probably helped tremendously that the Macintosh community was energized with the first introduction of Macintosh clones.
Lasso 1.1 was release as both the CGI, and a new WebSTAR plug-in, edition in December 1996, just two months following the release of version 1.0. This release introduced support for serving images directly from FileMaker Pro, triggering FileMaker Pro’s ScriptMaker scripts, along with access to client and browser information. Lasso 1.1 also provided it’s own layer of security for database communication at both the field and record level.
Following the release of the Lasso 1.2 lineup in January 1997, Blue World and the Bonfanti’s entered private talks with Claris, a spin-off from Apple Computer, and owner of FileMaker Pro. Claris eventually bought the post version 1.2 Lasso source code, and with the help of Vince and Paul Bonfanti released the FileMaker Web Companion as a component of FileMaker Pro 4.0.
FileMaker Web Companion's language, CDML (Claris Dynamic Markup Language), differed from Lasso 1.2’s LDML (Lasso Dynamic Markup Language), but was so close as to offer an easy transition for developers looking to serve from FileMaker Pro through third party servers.
The inclusion of the Lasso-like Web Companion in FileMaker 4.0, combined with the energy and buz surrounding Lasso at this time helped tremendously drive sales and mind share for Lasso in the rapidly growing Macintosh web development community. During this time period Blue World also moved their offices from Issaquah to the Plaza Center in Bellevue, Washington.
Blue World continued developing Lasso with Kyle Jessup stepping into the position of lead programmer. Lasso 2.0 was released in July 1997, introducing some fundamental shifts in how Lasso could be used.
Lasso 2.0 saw the addition of Lasso 2.0 Server to the lineup. Lasso Server was a Lasso-branded web server with the Lasso technology built in. This allowed greater integration between the server and the “middleware”, providing better performance. Lasso Server also allowed developers to set up a development environment without the associated cost and complexity of a third-party web server.
Lasso 2.0 was given new functionality including mathematical calculations, variables, more complex data types, server side includes, client header information, more advanced conditional statements, and a Java-client interface. Lasso 2.0 could also send Apple Events, thereby controlling other applications on the web server.
Most significant among the new functionality was the ability to perform multiple inline database actions, specified entirely on the response page. Prior to Lasso 2.0 all but the database and layout (analogous to table and view in non-FileMaker database systems) had to be passed as arguments from the requesting web page. With Lasso 2.0 this changed, and dramatically altered the way many Lasso developers designed their web applications.
For the beginning developer, Lasso 2.0 introduced Instant Web Publishing – a packaged solution that would serve any FileMaker Pro database on the web without the need to code custom scripts.
In December 1997, with the release of Lasso 2.5, Blue World introduced improvements in tag standardization and interoperability. Lasso also gained the ability to communicate with the WebTen web server - a porting of Apache to the Mac OS by Tenon Intersystems.
Lasso 5 - 7
On February 26, 2002 BlueWorld released Lasso 5, which is considered by many in the industry to be the 2nd most important software release in the company's history (the first release being Lasso 1.2).
Lasso 5 included, among many updates, a completely rewritten architecture (for OS X, Windows & Linux), and more importantly an embedded MySQL database. Lasso 5 still spoke to a FileMaker database (but not to a FileMaker Server, that wouldn't come until FMI actually allowed for the capability), FileMaker as a datasource was by many accounts slow by comparison to a SQL engine. A little history: Remember that FileMaker is a single threaded datasource, and as such that as requests come in they are handled in the order in which they are received. And single threaded behavior affects performance in terms of speed and responsiveness, as does how the database solution was developed, ie: does the database have calculations, are there subsummary layouts, are there any scripted result calculations (more than likely), are there graphics embedded in the container fields...etc. All of these things can affect the speed at which FileMaker arrives at the result at which a request was looking for. Thereby giving the appearance of it being 'slow'. Lasso itself, since v2.0, was fully multithreaded (allowing for many connections at once), it always succumbed to FileMaker's latency or 'lag' in certain operations, and there was no way to get around it reliably, other than to make major changes to your datasource.
Lasso 5 as a language, and server, could no longer rely on FileMaker as a backend, Lasso's future was literally tied to FileMaker's. By tying Lasso's future to another datasource it opened the possibility for greater usage and other opportunities. Many developers at that particular point were clamouring for greater speed (and had been for sometime), and then losing those developers because of its reliance on FileMaker. In the development world trying to sell Lasso to an IT department meant not only getting the client over the Filemaker Shock which typically didn't go over too well, and then to have to upsell Lasso on top of that was rather difficult at best. In every respect Lasso showed enormous promise, to gain marketshare, and world class developers. However its heavy reliance on FileMaker tied it to an uncertain future, and that future was written solely at FMI's discretion. So a decision was made to use an internal database, and that database was MYSQL.
Lasso was not only tied to just MySQL as a database, it also spoke SQL directly, and at the same time allowed the developer to continue to use the simplicity of the INLINE tag (see examples below) to become database blind. Which is to say that Lasso, as a language, didn't care what datasource it was talking to, just that there was data there. Furthermore, Lasso also could talk to any JDBC compliant datasource, as long as the connector for it existed, and BlueWorld supplied that basis for writing that connector. At the same time it also allowed for the developer and hosting provider to talk to an external MySQL datasource...all at the same time. The developer could, in effect, have their pages talk to MULTIPLE datasources and multiple TYPES of datasources and never have to change their code one bit. You could literally change datasources from page to page to page and the end user would never know it. You could, as a developer, combine FileMaker data, with MySQL, or Oracle data all on the same page, from the same server.
Lasso 5 also contains two other major advancements, both of which changed how a developer could deliver and deploy their solutions. The first of which was Sessions. Until this point in time, Lasso's only way to maintain state on a Lasso driven page was through cookies and token values. While cookies were ubiquitous on the web, token values were Lasso specific. Both allowed for the developer to create a stated environment on the page and within a website as a whole. Cookies and Tokens had been around with Lasso since v1.2. While developers had been wanting the ability to maintain state across the entire website for quite some time, there was effectively no global method to perform this action. Lasso 5 allowed for the capability to maintain state across the website, values and parameters such as login information, date, time, client header information, could all be containted within a single variable, or session, and then passed from page to page thereby creating the illusion that an end user's state is being maintained, and in reality it is being maintained. Lasso 5's other major advancement and at the time, an industry first, was the addition of Lasso Applications or LassoApps. A Lasso Developer now had the capability to create an entire web application and lock it down, thereby protecting their intellectual property. Such a LassoApp still had to be tied to a Lasso 5 Application Server, but this was a great improvement. It meant that a developer could literally write their application ONCE and distributed many many times over, and still holding the rights to their code. Both of these advents, along with an embedded MySQL server, and a completely re-written architecture and a host of new tags and services built-in to the language and application server literally gave a developer and any organization that used the tool, to go toe to toe with ColdFusion, ASP, or the upstart PHP based website.
Lasso 5 also had one other advancement, that didn't exist in previous versions of the language (or not without a whole lot of coding and ministrations to get the thing to work properly, or at all): file uploads. Lasso 5 had a built-in capacity to handle, manipulate, and then retrieve a file uploaded to a webserver.
Lasso 5 also saw the advent of not working with just Webstar 5, ASIP (which was replaced by OS X Server), or iTools (from Tenon, but it also had the ability to talk to Apache natively under OS X, Windows, and Linux (Mac OS 9, on which Lasso had been used for many years, was not supported). And at the same time rewrote the connector for Windows IIS5 and 6.
Lasso 5's other singular attribute, that literally changed the way a Lasso Developer creates pages was LassoScript. In short, LassoScript looks just like Lasso SquareBracketed Code (LDML) except that no encoding is applied to the result, unless specified. LP5 could now be coded for by splitting the logic from the display values and variables in a way that just wasn't possible before.
There was never a Lasso 4 release; the version number skipped from 3 to 5.
Lasso 6 saw the advent of imaging and PDF capabilities (among many other speed and stability improvements). Lasso 6 extended the capabilities brought to market in Lasso 5. Lasso 6 now had the capability to create a PDF on the fly, or to manipulate an image upload. While Lasso 5 had the capability to handle image and PDF manipulation and/or creation, it had to be tied to the OpenSource tool for such ImageMagick via Steffan Cline's wonderful suite of tools. Lasso 6 on the other hand, had ImageMagick built-in. That allowed for greater control over imaging capabilities.
Lasso 6 also had a host of new tags, most notably XML tags that allowed it to speak directly to an XML datastream. Lasso 6 also had the ability to talk directly to an FTP server, access its directories and then pull or push files to and from those directories, or display that data as part of a web page. Lasso 6 also added date math. Lasso 5 was a good stab at dealing with dates, however, how it reliably handled the pesky problem of date math eluded it. Lasso 6 re-wrote that model and improved on it greatly with duration tags. Take for example the fact that the web is a stateless place. And that very fact, eludes the idea of duration. Or in other words, how long between events or pages/actions. Traversing duration gets even more tricky if you're not working with any kind of saved state (a session), fortunately Lasso has embedded secure sessions (some may argue that the session variables for Lasso 5 - 8 are not long enough thereby creating a minor security concern). Lasso 6's Duration tags take a major stab at providing just such a pathway around that sticky problem.
Lasso 7 saw the advancement of the language in many different ways, most notably the removal of the ability to access the embedded MySQL version via an external client. Until v7.0 of Lasso you could open up a SQL client like CocoaMySQL, Navicat, or AquaDataStudio or any SQL client application and add/edit/modify your database and table structures. v7.0 removed that capability and at the same time BlueWorld told developers that they should really look at using an external MySQL version. While this move made a lot of Lasso developers rather unhappy, BlueWorld did provide a way to perform all of those functions that a SQL client would do, however it provided them in a web interface similar to phpMyAdmin but with fewer capabilities.
At around this same point in time, FileMaker expanded their offerings (to a degree), and moved some of the functionality that was previously embedded in the web companion and CDML into FileMaker Server, while Lasso could still talk to a FileMaker datasource, FMI closed down an avenue to allow that to happen, for whatever reasons. No 3rd party software could 'speak' directly to a filemaker database. All 3rd party applications had to go through FileMaker Server Advanced.
BlueWorld as a result had to change with the flow of where FMI was going with this, but again they weren't fully reliant on this move by FMI because they'd made the leap to an independent open source datastorage structure. The only way to access a FileMaker datasource at this point was via XML through FileMaker Server Advanced. This meant a change to any embedded images in a particular FileMaker datasource had within its container fields. However to BlueWorld's credit they went one step further than was required of them....they allowed for an FMSA datasource to be treated as just another datasource. Again independently of FMP v4-v6. So, in effect, Lasso could not only talk to an FMP v4-v6 directly and securely, but at the same time an FMP v7 datasource (via Server Advanced). It should be pointed out that FMSA7+ via XML is not secure at this point in time, however there are methods to make the transaction secure, and thereby Lasso has no way of securing the transaction of XML data that it receives or sends to an XML datasource that it does not control directly.
At this point in time this move by FMI did put an end to what many saw as other people/companies making money off FileMaker's technology. At the same time it also opened FileMaker to direct URL attack. It also made the datastream to and from Server Advanced extremely vulnerable since XML was not designed with security in mind. So in effect Lasso could no longer guarantee security to a FileMaker 7 datasource. That was the draw back of using LP7 with FMP7.
On August 1 of 2004, after 7 years of doing business as BlueWorld, Mr. Doerrfeld officially sold the Lasso product line to a company in Ft. Lauderdale, Florida - OmniPilot. Lasso 7.0.3 was the last version of Lasso released by BlueWorld.
Lasso 8.0 & 8.1
On October 25, 2004 OmniPilot officially announced the release of Lasso 8, and the next chapter in Lasso's future began. OmniPilot moved quickly in a series of releases to get developers on the same page, all heading towards this release: Lasso 8. In the span of 3 months they released nothing short of 4 updates to Lasso (point releases to be specific) and all the while working on Lasso 8.
From the outside looking in, Lasso 8 looks just like its predecessors. It does basically the same thing that every other version of Lasso does, it allows the developer to be able to pull data from a database and place that on a web page for all to see. However, how it does that and the tools employed is nothing short of mystical and blackboxish almost.
Lasso 8 also re-introduces the embedded database back to Lasso. In this iteration of Lasso the embedded datasource is SQLite. While this datasource can be used for data storage, it is not recommended.
Lasso 8 (or LP8), increases the emphasis on a distributed architecture. Prior to LP8, if a hosting provider wanted to make a change to its Lasso environment it affected all Lasso users, for better or for worse. From a hosting standpoint, Lasso was more suited to smaller ISPs that wanted to deliver FMP & MySQL web based functionality. If users wanted to do anthing serious in a hosting environment with Lasso, they needed to use a dedicated server in order to have complete control over the environment. With the introduction of LP8, the hosting provider now has the capability to allow individual control over each Lasso site. Each Lasso-driven site now runs as its own process. Furthermore with previous editions of Lasso, if the Application server went down, everything went down. In LP8 if the Lasso Application Server dies, its child processes continue, because they are independent processes. LP8 also opened the door to other products, such as Lasso Studio for Eclipse.
Lasso 8.5 was officially released to the Lasso developer community on June 9, 2006. After spending several months in beta, OmniPilot improved the functionality sets introduced in Lasso 8.0 improving the stability and greatly expanding the feature set for 8.5. 8.5's feature set includes but is not limited to the following: Full AJAX integration, allowing the developer to easily integrate and take advantage of AJAX and its methodologies; Multiple datasource connectors pre-installed, previous versions of lasso came standard with a connector for FileMaker, FileMaker Server Advanced, MySQL, & SQLite. 8.5 adds to that MS SQL Server, Sybase, Oracle, PostgreSQL, OpenBase, ODBC, and Apple's Spotlight engine. 8.5 also allows for an open ended SQL connector; the developer can call a datasource remotely from within their code, without having to redefine the datasource every time; Lasso 8.5 allows OS Level commands to be passed directly to the underlying operating system. Previously this was achieved through a 3rd party tool called "PassThru" by Steffan Cline of ExecuChoice.net. Lasso 8.5 also sports multiple result sets from a single inline call. There are many other new features as well.
One such new feature, which many current Lasso developers will appreciate, is the new developer tool. Lasso 8.5 runs in Developer Mode by default, without the need for a purchased license code. It allows the developer to test their solution on a live server with only two limitations: IP count (in developer mode: up to 5), and thread count (200). While not appropriate for production server use, this capability is ideal for development, and for demonstrating functionality to clients. Lasso 8.5 also comes with an educational package that allows educators to create a curriculum based on Lasso.
(March 5, 2007) - LassoSoft, LLC announced their acquisition of OmniPilot Software and the Lasso family of products during the keynote of the Lasso Developer Conference (formerly known as the Lasso Summit) in Fort Lauderdale, Florida. The Lasso Developer Conference is an annual gathering of Lasso users which includes presentations from LassoSoft employees and some of the most experienced Lasso users from around the world as well as training sessions for new Lasso users.
LassoSoft, LLC is a partnership of Kyle Jessup, Fletcher Sandbeck, and Kerry Adams. Kyle Jessup has served as the director of Lasso development since version 1.5. Fletcher Sandbeck is the primary developer behind the Lasso Studio product line and the primary author of Lasso's print and online documentation. Kerry Adams was previously the director of sales at OmniPilot Software. Collectively, the three partners have over 20 years experience working on the Lasso product line.
- Lasso Studio for Golive
- Lasso Studio for DreamWeaver
- Lasso Studio for Eclipse
- LDML plugin for BBEdit
- LDML Syntax Coloring Scheme for EditPad Pro