| By Nicholas Petreley | Article Rating: |
|
| November 11, 2002 12:00 AM EST | Reads: |
14,013 |
(LinuxWorld) — Python is one of the most versatile languages on the planet. Here are a few examples of the language's well-roundedness:
- You can use it to write sophisticated object oriented works of art
- You can toss together something akin to a shell script
- It can be multi-platform
- It can be platform-neutral
- It can generate Java byte codes
- You can write full-blown GUI applications with Python
- You can choose from among several GUI frameworks including Qt and Gtk
- Python makes a dandy Web-application language
In my last article, I described a relative newcomer to the Python server-side scripting solution category: spyce. Spyce is a versatile means of integrating Python code into HTML and vice versa.
If you're coming from a PHP background, you may not get the results from spyce and Python that you have come to expect from PHP. Whether this is a good or bad thing is something you'll have to decide for yourself, but you should be aware of these differences before you start a spyce project.
One obvious difference between spyce and PHP is in how each are interpreted or compiled. This affects code that you may want to keep in files to share among projects by including those files. The interpretive nature of PHP tends to allow you to be more dynamic with your methodology than spyce, although you can work around the differences if you get used to the way spyce and Python work.
There are some basics you'll need to know before we get to the differences. First, the simplest way to create a spyce document is to embed Python statements into an HTML page, one at a time. You can do that by enclosing a single statement in double square brackets such as, [[statement]]. For example:
<html><body> Hello [[print 'World!']] </body></html>
You can also print the contents of a variable directly, without using the print statement, by adding an equal sign after the opening brackets. For example, if the variable welcome is set to World!, then you can use the following to print Hello World!. Obviously, you'll need to set the value of the variable welcome ahead of time.
<html><body> [[welcome='World!']] Hello [[=welcome]] </body></html>
If you want to write a series of Python statements, add a backslash to the opening brackets. This method is especially convenient if you want to generate even the HTML from Python. For example:
[[\ welcome='Hello World!' print '<html><body>' for i in range(5): print welcome print '</body></html>' ]]
Note, of course, that the print welcome statement must be indented for the statement for i in range(5): to affect it. That's the primary way Python parses code. (Flame bait: You can use curly braces, too, but real Python programmers use whitespace.)
Even when we write the code in statements enclosed in brackets separately, the value of welcome is persistent through the main file and can be set or changed by any statically included files. For example, let's create a separate spyce file where we'll put commonly used functions and classes. We'll call this file classes.spy. We'll put two functions and two classes in it. (It's not needed here, but note that triplets of single-quotes are possible in spyce, just as they are in Python.)
File: classes.spy
[[\
def openHTML():
print '''<html><body>''' def closeHTML():
print '''</body></html>'''
class doHello:
def printHello(self):
for i in range(5):
print 'Hello world<br>'
class themeColor:
def getColor(self):
return 'blue'
]]
Now we can include the classes.spy file in our main index.spy file and make use of the classes and functions. You do this with the spyce directive include. Spyce parses a statement as a directive when you add a dot after the opening brackets, such as [[.directive]]. First, the code generates the opening html, then plays with a couple of classes from the classes.spy file. You instantiate the themeColor class with the simple statement c=themeColor(), after which you can access its methods.
File: index.spy
[[.include file=classes.spy]] [[\ openHTML() c = themeColor() tc = c.getColor() print tc x = doHello() x.printHello() closeHTML() ]]
When it comes to sharing information and included files, however, the operative word is static. The information in classes.spy is available to our program because we used the static method of inclusion, which is the directive .include. This directive only takes a static string. One cannot specify the file name with a variable so that your program decides which file to include as it executes.
How to include files dynamically
Fortunately, Spyce also features a method to dynamically include files. Here's how you might do that. I've also structured the program a little differently so that I can group the various stages of execution in a way that is visually appealing to my style of programming. For example, the openHTML() takes place in its own brackets not for any programmatic reason, but so that it's obvious that this is necessary regardless of what else goes on in the program. This is purely a matter of personal taste, so you can disregard the practice if you have other priorities.
The method c.getColor() will return the string blue, so the theme_name variable should inevitably be set to blue_theme.spi before we use it (the extension .spi is a convention for naming spyce include files, but you could also name this file .spy and it will work the same). Here are the contents of the file, blue_theme.spi, which we will dynamically include in our program:
File: blue_theme.spi
[[\
class blueResponse:
def returnColor(self):
return('<br>Love is blue.<br>') b = blueResponse()
color = b.returnColor()
print color
]]
[[ print color ]]
I included the print color command twice, separated by brackets to illustrate that the contents of the variable color is persistent across brackets within the dynamically included file. However, as you'll see, the change in value of the variable color does not persist into the main file. I'll demonstrate this by setting color before the dynamic include, change it within the included file and then print it again after the include. In order to do a dynamic include, we have to import the spyce include module. That's why the [[.import]] directive appears in the code.
[[.import name=include]] [[.include file=classes.spy]] [[ openHTML() ]] [[\ c = themeColor() theme_name = c.getColor() + "_theme.spi" ]] [[\ x = doHello() x.printHello()color = '<br>Love is purple.<br>'
print color
include.spyce(theme_name)
print color ]] [[.include file=colorchange.spy]] [[ print color ]] [[ closeHTML() ]]
If you were paying attention, you probably noticed that I inserted yet another static include at the bottom of the main file. The contents of this included file, colorchange.spy are:
File: colorchange.spy
[[ color='<br>Love is green.</br>' ]]
The program prints out the value of color once again after this static include. What you'll see when you load index.spy is that the value of color persists across the dynamically included file that also has the variable color and changes it. However, the value of color does not persist across the statically included file that attempts to change it, because that included file became part of the source code index.spy at compile time.
Here's the output you should see (excluding my comments in {} braces)
Hello world {output of the for loop from classes.spy}
Hello world
Hello world
Hello world
Hello worldLove is purple. {the value of color we set in index.spy}
Love is blue. {the value of color we set in the dynamically included
blue_theme.spi}
Love is blue. {ditto, even across brackets}
Love is purple. {the value in index.spy is unchanged}
Love is green. {the value was changed by colorchange.spy}
There's a good reason why I chose to name the dynamically included file blue_theme.spi. Many PHP programmers use techniques like these to make their sites multi-theme-friendly. In other words, some PHP programmers are used to looking up a user's color preference and then using that to generate a file name at run-time, such as blue_vars.php or green_vars.php. These files contain different configuration settings your main program uses at run-time in order to set the colors for the theme. Obviously, this won't work with spyce dynamic includes because the main program won't "see" those settings in the dynamically included file.
It isn't impossible to accomplish the same basic task with spyce, but you simply have to keep in mind that whatever you do in the dynamically included file must be self-contained. Spyce programmers have yet another more-elegant alternative, which I'll cover in my next article.
Published November 11, 2002 Reads 14,013
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Nicholas Petreley
Nicholas Petreley is a computer consultant and author in Asheville, NC.
- Kindle 2 vs Nook
- Is Cloud Computing Like Teenage Sex?
- GovIT Expo Highlights Cloud Computing
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- Cloud Computing Can Revitalize Your Career as Software Developer
- Ubuntu-based Open Source Linux Mint Tests KDE Version
- Yahoo! SVP Shelton Shugar to Discuss Innovation at Cloud Computing Expo
- Virtualization Journal "Readers' Choice Awards" Voting Is Now Open
- Einstein, Sharks and Clouds: IT Security in the Cloud
- Adobe Flex Developer Earns $100K in New York City
- Virtualization Expo Call for Papers Deadline December 15
- Amazon Web Services Database in the Cloud
- Kindle 2 vs Nook
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- Is Cloud Computing Like Teenage Sex?
- 1st Annual GovIT Expo: Letter from the Technical Chair
- Ulitzer News: Search vs New Media
- The Difference Between Web Hosting and Cloud Computing
- Cloud Computing Expo: Exclusive Q&A with Yahoo! SVP Cloud Computing
- Confessions of a Ulitzer Addict
- GovIT Expo Highlights Cloud Computing
- Twitter, Linked In, Ning and Ulitzer: Easy Personal Branding Strategy
- My Thoughts on Ulitzer
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- The i-Technology Right Stuff
- Linux.SYS-CON.com Exclusive: Linus Discloses *Real* Fathers of Linux
- After Ubuntu, Windows Looks Increasingly Bad, Increasingly Archaic, Increasingly Unfriendly
- Linus' Top Ten SCO Barbs
- A Closer Look at Damn Small Linux
- Netscape Co-Founder's 12 Reasons for Growth of Open Source
- Introducing "Cooperative Linux" - Linux for Windows, No Less
- *POINT - COUNTERPOINT SPECIAL* What's Wrong with the Open Source Community?
- Where Are RIA Technologies Headed in 2008?
- Linux.SYS-CON.com Exclusive: What Would UserLinux Look Like?
- i-Technology Viewpoint: The New Paradigm of IT Buying
- Is Linux Desktop-Ready Yet...or Not?




























