B_Template: Deep-sixing Includes
B_Template is the first installment in my B-Suite of custom types, and can be used to apply multiple consecutive changes by regular-expression to a text-file. The text-file is then sent to the client as the final content body. I built this to separate the front-end of my web applications, from my middleware code, and avoid an octopus-like tangle of included files. The current B-Suite source can be checked out from the Google Code.
Typically you’ll use the Include tag to dynamically patch together each webpage from a header, footer, sidebar, code libraries, etc. I’ve found this becomes difficult to manage as the size of the website, or number of participants, increase. Instead, I wanted to keep the front-end self contained, and then dynamically apply generated content.
For a very simple example, an HTML page can stand alone, and be easily managed with many available tools.
<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Insert Title Here</title>
</head>
<body>
<h1>Insert Header Here</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</body>
</html>
A script file can then pull together the data, and apply it to the above template.
<?LassoScript
Inline( -Database='db',
-Table='tb',
-Username='un',
-Password='pw',
-SQL='SELECT `title`, `header` FROM `tb` LIMIT 1');
B_Template('/path/to/template.html',
-Type='text/html',
'Insert Title Here'=Field('title'),
'Insert Header Here'=Field('header'));
/Inline;
?>
Of course, the above is an exceedingly simple example. You can also use regular expressions to specify changes, and structure your usage more programatically using member tags.
<?LassoScript
Local('mytemplate' = B_Template);
#mytemplate -> Location('/path/to/template.html');
#mytemplate -> Apply(RegExp(-Find='(?<=<title>).*(?=</title>)', -Replace='My Title'));
#mytemplate -> ServeAtEnd;
?>
There’s control over when the current instance of the template is served to the client, what MIME type is used, and whether to apply the changes to the current instance or start again with the original template. Using B_Template, you can also extract sub-templates from the original, which allows example structures in the original template to be looped over and appended to with changes.
There’s more information in the project wiki — or will be shortly. I’d love any feedback, so please leave a comment with your thoughts.
Started B-Suite Project on Google Code
I’m working on several custom tags and types for release to the Lasso community. Collectively I’m refering to these as b-suite. I’ve created a new project up on Google Code, and as each new tag or type is released, I’ll add it to this project.
I’ve chosen to release this code under the MIT License, which seems to me to provide all the rights you could possibly want. If your organization requires anything more, please contact me.
At this time b-suite is coded for Lasso 8.5.5. I have several custom tags and types planned for inclusion, and have Lasso 9 versions in the works. Watch this blog for announcements when each tag or type is added to the public repository, and please leave me a comment, or email me directly, if you put any of my code to work in your projects.
A First Look at L-Unit™ 2.0
For anyone conversant with Test Driven Development, it’s enough to say that L-Unit™ is a unit testing environment for Lasso code. For the rest of us, L-Unit™ is a framework upon which you can setup, store, and run tests of your custom types. These tests are abstracted from your application as a whole, and only act upon an individual “unit“. The developers say this helps you avoid the “whack-a-mole” type debugging one inevitably engages in when revising a broad or complex code-base, and I can certainly see how L-Unit™ will help.
Setting up L-Unit™
I’ve heard about L-Unit™ for years, but I never paid much attention to it until last September’s Lasso Developers Conference. So, about a month ago I downloaded a zip-archive of the application from http://www.l-unit.org/. The developers recommend checking out the Subversion repository instead, which makes a lot of sense — the zip file I downloaded was created early October, while the repository was last updated a month later — but I was being lazy. Besides, while I use Subversion daily, some developers are not yet comfortable with SVN. I plan on publishing a second article on L-Unit™ after I’ve used it a bit more, and I’ll base that second article off of the code-base checked out from the repository.
I started by reading through the first 24 pages of the manual. The last 3 pages are reference material, and can be skipped until you start coding. The “Quick Setup Guide” is on page 24 of the manual, which seems an odd location. But, it being there guided me towards reading the manual before I started, which was perhaps the writer’s intention. The “Quick Setup Guide” is available as a separate download as well.
After reading the manual, it was pretty obvious I needed to rework many of my settings in Lasso’s ServerAdmin. I had about 15 websites already running on my development machine, but rather than create a separate Lasso site for each, I had only configured the default site. This wouldn’t do, since L-Unit™ should run in a default environment. So I moved everything in under a new Lasso site instance, and created a second new Lasso site just for L-Unit™.
Starting with a clone of an example test case , I created a very simple test case for a custom type I had recently completed. This was putting the cart before the horse in the Test Driven Development methodology, but I thought I would learn a bit more this way.
Boom. I hit my first brick wall, if not a particularly high one. Belatedly realizing that L-Unit™ must parse through my class-files, custom type files in Lasso parlance, I ran a chmod command on the site’s root directory to allow write privileges for everyone.
chmod -R go+w unit
Changes to my code
I found that I needed to adjust my coding style to fully utilize L-Unit™. The custom type I had chosen had only three member tags. One of these member tags was fairly complex, but none of the enclosed-code was duplicated anywhere else. Also, the complex member tag had no return value — it simply set or modified a global variable. To test the code within the complex member tag granularly enough to make a difference, I needed to split it up into many smaller tags, and make each one return some value. While this might seen a bit intrusive on the part of L-Unit™, I think the end result is a better bit of coding on my part than what I started with.
When I finished with my a successful test case for that first custom type, I moved onto a second. This was actually a custom tag. The test setup for a custom tag was identical to that for a custom type. Again, granularity in my own code was a must. I ended up re-coding my tag into a custom type, but just get into the mindset of building a bunch of small constructs, instead of one big one. Intrusive? Yes, but again I liked what resulted from my re-coding. And, I didn’t actually change the usage for the resulting code.
Finally, when I created my first test for this second custom type, I was at first a bit confused. I code all of my custom types and tags for a given namespace within a single file. So, naturally I tried coding my second test case in the same file as my first. Since the two constructs I was testing are in the same file, this made perfect sense. Well, apparently not to L-Unit™. Oh well, once I stumbled upon the answer it wasn’t a huge paradigm shift to build one test case per file.
What I don’t like
The PDF manual I downloaded doesn’t allow copying and pasting. Any such attempt results in gibberish. Perhaps I’d have better luck with Acrobat Reader, rather than Apple’s Preview. The way around this annoyance is to use the Google Doc version of the manual. I had downloaded my copy of the manual from the “Downloads” page, rather than looking on the “Documentation” page where the Google Doc version is mentioned.
I found it difficult to debug errors shown by L-Unit™ during a test run. The information returned was fine, but since each test is run asynchronously there are few if any means of pulling out more information. I’d like to see some method of viewing the content_body from each run of a tag within L-Unit™. It’s possible a construct like Log(-Window) would help push debugging information out to the Lasso Service console, but I haven’t tried this yet.
Of course, I’d like to see L-Unit not rely on non-standard file suffixes, but I’ve already detailed my reasons for this in an earlier post. It is nice to see the numerous warnings against running L-Unit™ in a production environment. But, such a warning should be for performance reasons, not security.
What I do like
The application’s user experience is very polished, which is refreshing to see in an application intended for admins. And, while the documentation has some small errors and could use a bit more information, it’s rather polished as well.
Others might complain more about the need to adjust their own coding structure to maximize the usefulness of L-Unit™, but as I said before, I liked the results. I probably should have been coding more like this for years. Of course I really should have built my test cases first, and then written my code to satisfy those tests. So changes in my architecture would have seemed more natural from that perspective.
Conclusion
I probably could have had any questions answered pretty quickly by posing them on the LassoTalk mailing list, or emailing the current developer directly. But I think a number of developers hesitate before asking questions, not wanting to appear the “newb”. By sorting through the issues alone, I got a sense of what they would be going through. Either that, or I just didn’t want to appear the “newb” myself.
I’m looking forward to using L-Unit™ on several upcoming projects, this time coming at the code in the correct order, with the test-cases first and the application code after. I’ll need more time to fully form an opinion, but at this stage I’m optimistic that L-Unit™ will become a standard part of my work flow.
A fews more things
L-Unit™ was originally developed by Greg Willits, and has more recently been driven by Ke Carlton. Both should be commended for their respective efforts. Ke is the one who gave the L-Unit™ presentation at last year’s Lasso Developers Conference, and finally got me to take a look at the application.
Greg Willits also developed PageBlocks™, L-Revolver™, L-Migrator™, and L-Debug™ — which I speculate might satisfy my desire for more debugging capability within L-Unit™. It’s not my intent to write about any of these other offerings at this time. This posting is intended to reflect solely on L-Unit™ 2.0.
Do you have any experience with L-Unit™, past or present? Did I miss anything, or get something wrong? Make yourself heard in the comments.
Open Sourcing? Stick with Standard Suffixes
When developing web applications for download by the open community, stick with default suffixes for files containing server processed code, and avoid non-standard suffixes not mapped in a default install.
I posted on the LassoTalk mailing list the other day about avoiding non-standard file suffixes when building applications for others to download. I’m going to revisit that topic here, for readers who might not subscribe to LassoTalk. And, because I know I’ll refer back to this topic in future posts.
Lasso is my web development platform of choice. For those unfamiliar with this platform, it’s roughly similar to PHP but with a much more cohesive language and far fewer security problems. With a default install of the Lasso environment, client requests to the webserver with “.lasso” or “.lassoapp” suffixes are handed off to the Lasso engine for processing — exactly like “.php” for a PHP install. Requests with other suffixes are handled differently depending on the suffix mapping for the given webserver, but most webservers serve unknown suffixes as plain text.
It’s become common, recommended by some, for Lasso developers to use a variety of non-standard suffixes. Among the most frequently seen are “.ctag”, “.ctyp”, and “.inc”. Proponents of this practice do this so they can easily tell from a file’s name what purpose a file has. Some proponents also routinely configure their webserver to not serve these files directly in response to a client request, improving security.
Both of these reasons are well and good. Code should be easy to read, and that extends even to the file names. And, securing libraries that are not intended to be called directly helps keep private information; well, private.
However, there are other ways to accomplish the same things. For example, you could use a standard suffix, while turning the string in question into a prefix. So instead of “header.inc”, you’ll end up with “inc_header.lasso”. This actually will have the added benefit of grouping like-files together. But, if you like the order your file names are in now, “header_inc.lasso” will work just as well.
For restricting access to these same files, an “.htaccess” file, or another mod-rewrite rule, can be used to restrict access to those files. For example, the following works with Apache2 and prevents both access to anything with “_inc” in the filename or path, and any hit to Lasso for such requests.
RewriteRule _inc access_denied.lasso [NC,NS,L]
Of course, the reason you should stick with default suffixes for downloadable web applications is security. If you’re responsible, you must code defensively. This means assuming other layers of your security will be compromised. Like, for instance, an inexperienced admin setting up their environment to serve a non-standard suffix, but not execute that same suffix. This is easy to do, and results in a perfectly working web application where key blocks of raw-code can be viewed at known URLs which are not commonly checked.
If you always use the standard suffixes available in a default install, then no amount of URL-hacking will result in raw-code being served. The worst possible result will be for the code of the included file to be processed out of sequence, and you can code defensively for that as well.
I’m not suggesting that you should never use a non-default suffix. I’ve seen a website, for marketing purposes, use their phone number as a suffix — although I would suggest using mod-rewrite to achieve this trick. But use non-default suffixes only within your proprietary code, where you have complete control of the environment, and only yourself to blame for a mixup.
Feel I’m off base with this? Please leave your thoughts in the comments.
Welcome
Welcome to my new blog! I’ll be posting articles mostly on web application development using Lasso, JQuery, various CSS-frameworks, and any other technology I end up using regularly. My focus over the last year has been integrating third-party frameworks and services into my personal work cycle, to improve my own efficiency and deliver more value to my clients.
Coming up quickly, I’m planning a review of L-Unit™, which I’ve been working to integrate into my work flow. I also have a suite of custom tags I’ll be releasing. In the mean time, I can be followed on Twitter, or you can see my LinkedIn profile, and please feel free to contact me at solutions@douglasburchard.com.
Please come back often, or better yet just subscribe to the RSS feed, to see what I have in store.
Douglas Burchard has been creating professional data-driven web applications with Lasso since before it’s initial launch in 1996.
