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. Within the developer's Lasso code, the call for data is made to 'info' using the Lasso data manipulation tags. 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. 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. Example 2 - Portability A developer maintains local and remote copies of the same data source.
Software Updates via MacUpdate
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.
This allows developers to set security parameters via a broad range of factors. The last one is of course the easiest. 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.
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. Lasso language is not case-sensitive. 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. Both also required use of FMP calculation fields for formatting, which I found tedious and error-prone. That CGI eventually became Lasso 1.
At this point Lasso only worked with FileMaker Pro 3. 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. Following the release of the Lasso 1. Claris eventually bought the post version 1. Lasso 2. Lasso Server was a Lasso-branded web server with the Lasso technology built in. Lasso Server also allowed developers to set up a development environment without the associated cost and complexity of a third-party 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.
Thanks for signing up!
With Lasso 2. For the beginning developer, Lasso 2. In December , with the release of Lasso 2. Lasso 3. 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 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. 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.
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 You could literally change datasources from page to page to page and the end user would never know it.
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. 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. 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.
- Quick Overview?
- Sites by me?
- Communal Utopias and the American Experience: Religious Communities, 1732-2000;
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. 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. Lasso 6 on the other hand, had ImageMagick built-in.
That allowed for greater control over imaging capabilities. 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. This would keep you form having to do any janky FMSA certificate changes.
Lasso Development Services
There's shenanigans afoot. Do that on the command line with curl. What do you get? There is a known issue with macOS Michael Benedict. Submitting a list in a single form?? In reply to this post by maxwellk2. Hello, I know you can do this, but can't make it work. You have a list of names. This list is displayed vertically on the page.
Mike Sally Nancy Next to each name is a Check box. If you check that box you want to add that person to a data file.
Workforce Management Software that Simplifies Crew Scheduling | LASSO
Event Registration for instance Can you submit the list within a single form submittal and add only those you "check off"? Jolle Carlestam Re: Submitting a list in a single form?? Is this Lasso 8 or 9? Sent from a mobile device. Any anomalies is due to Autocorrect.
RE: Submitting a list in a single form??