Since I moved to Django I've been struggling with the question of how to keep the site's body content up to date. I started out just editing the body pages' HTML, which was stored in the database (crude, but it did allow an earlier transition to Django).
I've since experimented with various mechanisms, including two WYSIWYG editors in the Django admin (not sufficiently expressive) and a full content management system (too cumbersome and tricky to install, though it may become the favored solution eventually). For now I've settled on a scheme that allows me to keep the body page text in the database as either ReStructured Text or raw HTML, but I am sure this is far from the best answer.
So how do you keep your web's textual content up to date without going crazy?
"Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C Clarke
Musings from the technological frontier
Showing posts with label web development. Show all posts
Showing posts with label web development. Show all posts
December 11, 2009
June 5, 2009
Google Wave: A Reason to Learn Java?
I've just (finally!) finished viewing the developer preview video of Google's Wave project from the recent Google I/O gathering. If I had time I would be brushing up my Java right now. I understand that the Java world was somewhat upset that Google App Engine supported only Python as a programming language for so long. Well, Wave is based on the Google Web Toolkit (GWT), a fascinating development platform that allows you to program in Java and deliver AJAX applications automatically translated (on the client side) into JavaScript. So now it's time for us Python guys to stand in line.
Wave is an amazing demonstration of where the web is going, and our lives are going to be richer for it. It's an entirely new approach to personal communication, and clearly demonstrates that open architectures are (pun intended) the wave of the future. Google are actively looking for people to get involved with the project already.
More later. For now I am too blown away to do much more than sit here thinking about the potential. I am also excited that this represents a bundle of opportunities for the open source world to demonstrate technical leadership. Unless other vendors have come up with some competing web-based technology I'm not aware of, and I'd be happy to learn about that too.
Information about the Wave platform (and, of course, the open source code) is on Google Code. The open Wave protocol details are on a separate site. Look for Wave's public arrival later in the year. Nice job, Google.
Wave is an amazing demonstration of where the web is going, and our lives are going to be richer for it. It's an entirely new approach to personal communication, and clearly demonstrates that open architectures are (pun intended) the wave of the future. Google are actively looking for people to get involved with the project already.
More later. For now I am too blown away to do much more than sit here thinking about the potential. I am also excited that this represents a bundle of opportunities for the open source world to demonstrate technical leadership. Unless other vendors have come up with some competing web-based technology I'm not aware of, and I'd be happy to learn about that too.
Information about the Wave platform (and, of course, the open source code) is on Google Code. The open Wave protocol details are on a separate site. Look for Wave's public arrival later in the year. Nice job, Google.
July 22, 2008
Django 1.0 Alpha 1 released
We learned yesterday that the Django development team had released the first alpha on the trail to the 1.0 release due early in September.
This is great news: it means that the major items that have been developed on the sidelines (a refactoring of the queryset code and a rewrite of the admin application to use NewForms) are now fully merged into the trunk. Most of the functionality for the eventual release is now in place, though of course the feature freeze doesn't start until the betas, scheduled for two weeks time.
This is great news: it means that the major items that have been developed on the sidelines (a refactoring of the queryset code and a rewrite of the admin application to use NewForms) are now fully merged into the trunk. Most of the functionality for the eventual release is now in place, though of course the feature freeze doesn't start until the betas, scheduled for two weeks time.
April 8, 2008
Google Busts the Web Wide Open - In Python!
Well, if ever there was a compelling reason for using Python it's probably Google App Engine. Here's the canonical "hello world" Google App:
There's a lot behind this announcement, including a detailed description of the data store (which interestingly seems to bear the same kind of relationship to a classical relational database that Python does to statically-typed languages), access to some of the attributes of authenticated Google account users, the ability to fetch remote URLs and a startlingly straightforward way to send email.
If I were going to write another book about Python web programming I wouldn't be able to ignore this development. What a tempting idea ...
print 'Content-Type: text/plain'Doesn't get a lot simpler than that, does it?
print ''
print 'Hello, world!'
There's a lot behind this announcement, including a detailed description of the data store (which interestingly seems to bear the same kind of relationship to a classical relational database that Python does to statically-typed languages), access to some of the attributes of authenticated Google account users, the ability to fetch remote URLs and a startlingly straightforward way to send email.
If I were going to write another book about Python web programming I wouldn't be able to ignore this development. What a tempting idea ...
Twisted Bite the Web Bullet
The Twisted community has decided it's time to clean up its web act. The problem for a while has been that there were three "competing" packages that might have formed the basis of any web application: twisted.web, nevow and twisted.web2.
Now they have decided that twisted.web is the right namespace, and the immediate plan is to backport the stable functionality from web2 and the nevow application server into twisted.web, giving a more advanced set of web functionality in a way that offers best compatibility to existing users. Nevow will intially remain, as a pure templating solution, but there's a possibility that functionality might also be repositioned eventually.
This has the smell of a compromise, but as compromises go (and as you'd expect in the Twisted world) it seems to be a pragmatic engineering solution to the current rather confusing situation.
Now they have decided that twisted.web is the right namespace, and the immediate plan is to backport the stable functionality from web2 and the nevow application server into twisted.web, giving a more advanced set of web functionality in a way that offers best compatibility to existing users. Nevow will intially remain, as a pure templating solution, but there's a possibility that functionality might also be repositioned eventually.
This has the smell of a compromise, but as compromises go (and as you'd expect in the Twisted world) it seems to be a pragmatic engineering solution to the current rather confusing situation.
March 14, 2008
Getting Started with Pylons/TurboGears 2: Modern Python Web Development
This presentation was as frustrating for me as it probably was for the presenters, Mark Ramm and Ben Bangert. Unfortunately the examples for the first part of the tutorial relied on having up to date copies of lots of packages, and the audience were unable to download them from the Internet as the hotel staff appeared to be having some difficulty connecting 500 geeks to the fat Internet pipe through their wireless infrastructure, and connectivity was extremely intermittent.
Things went from bad to worse when I finally managed to download the required software from the Internet and found that my examples failed: it turned out that only the presenters' machines had the necessary combination of packages. Consequently a lot of the first hour was wasted in trying to organize a thumb-drive bucket-brigade to ensure that all present had the needed stuff loaded. I can understand Mark's anxiousness to present the latest and greatest TurboGears to the audience, but I was there primarily because I wanted to get back into the technology so as to be able to make fair comparisons with Django.
While we were trying to get the load problems sorted out, mark talked about the WSGI interface and its role as a standard in the Python web world. He then talked us through a couple of practical applications, and I ended up with a simple server working based on the reference implementation, wsgiref. We then implemented the same functionality using cherrypy.wsgiserver, observing that the fundamental techniques weren't particularly different. The third exercise didn't actually add much for me, since we just had to get the existing servers to replace the initial output with a listing of the environment dictionary.
Then we moved on to TurboGears. Alas, I ended up typing in code from the handout while Mark was explaining the supporting functionality, and when all was said and done I didn't notice a lot that was new in terms of how you put a TurboGears application together. In one way this is very good, because it means that the TG re-implementation has retained the same API that its developers have become familiar with; in another it's bad, because I didn't feel I actually learned all that much as someone who had already put TG applications together, albeit small ones. Much of what was said was narrative about the state of the software rather than directed towards learning the technology. I didn't have the sample web finished, with nine pages remaining of the handout by the time Mark's part of the session was over.
Ben Bangert then proceeded to explain the differences in philosophy between TurboGears and Pylons. I'm sorry to say that my experience on the first rather-more-than-half of the tutorial left me unable to concentrate sufficiently, and I didn't absorb as much as I would have liked. I don't remember any practical work at all, and I didn't end up with a handout, but I don't know whether I missed it or what.
This was the first of a matched pair of tutorials, the second discussing advanced use of TG and Pylons. I didn't attend it because I was booked on something else in the evening session, so I hope that those who did found that this tutorial had provided them with the necessary background.
Things went from bad to worse when I finally managed to download the required software from the Internet and found that my examples failed: it turned out that only the presenters' machines had the necessary combination of packages. Consequently a lot of the first hour was wasted in trying to organize a thumb-drive bucket-brigade to ensure that all present had the needed stuff loaded. I can understand Mark's anxiousness to present the latest and greatest TurboGears to the audience, but I was there primarily because I wanted to get back into the technology so as to be able to make fair comparisons with Django.
While we were trying to get the load problems sorted out, mark talked about the WSGI interface and its role as a standard in the Python web world. He then talked us through a couple of practical applications, and I ended up with a simple server working based on the reference implementation, wsgiref. We then implemented the same functionality using cherrypy.wsgiserver, observing that the fundamental techniques weren't particularly different. The third exercise didn't actually add much for me, since we just had to get the existing servers to replace the initial output with a listing of the environment dictionary.
Then we moved on to TurboGears. Alas, I ended up typing in code from the handout while Mark was explaining the supporting functionality, and when all was said and done I didn't notice a lot that was new in terms of how you put a TurboGears application together. In one way this is very good, because it means that the TG re-implementation has retained the same API that its developers have become familiar with; in another it's bad, because I didn't feel I actually learned all that much as someone who had already put TG applications together, albeit small ones. Much of what was said was narrative about the state of the software rather than directed towards learning the technology. I didn't have the sample web finished, with nine pages remaining of the handout by the time Mark's part of the session was over.
Ben Bangert then proceeded to explain the differences in philosophy between TurboGears and Pylons. I'm sorry to say that my experience on the first rather-more-than-half of the tutorial left me unable to concentrate sufficiently, and I didn't absorb as much as I would have liked. I don't remember any practical work at all, and I didn't end up with a handout, but I don't know whether I missed it or what.
This was the first of a matched pair of tutorials, the second discussing advanced use of TG and Pylons. I didn't attend it because I was booked on something else in the evening session, so I hope that those who did found that this tutorial had provided them with the necessary background.
December 30, 2007
Starting to Understand Django
Given a fairly quiet holiday season I wanted to try and make some sense of Django, having formerly given TurboGears a look (though not yet having written that up). Both are capable systems whose designers I have a lot of respect for, so it would be nice to master their elementss. Each in its own way has the potential to improve web productivity, though it remains to be seen whether I have the headspace for all of both systems given their complexity.
After a couple of days messing around with Django I am at the stage where I have imported the Holden Web database model using Django's introspection features. A deal of cleanup was required, as well as a certain amount of reordering—most of which would not have been necessary if I'd had the sense to delete the Django admin tables from mo model, since I doubt I will need to manipulate them directly. Anyway, it's rather nice to see that the following views.py can generate the almost home page shown above:
from django.http import HttpResponse
from django.template.loader import get_template
from mainapp.models import Section
def homepage(request):
seclist = Section.objects.all()
hpdict = dict(("secPathZone%d" % s.sechomeslot, s.secpath) for s in seclist)
return HttpResponse(get_template("homepage.html").render(hpdict))
This is neat, though I have an idea that rendering the unnumbered lists to add the missing link sets is going to involve me in a little more work than I have had to do so far. Still, it's an encouraging start. I am serving this web from a local Apache server using mod_python to control Django and serving static content (images, CSS files) directly.
After a couple of days messing around with Django I am at the stage where I have imported the Holden Web database model using Django's introspection features. A deal of cleanup was required, as well as a certain amount of reordering—most of which would not have been necessary if I'd had the sense to delete the Django admin tables from mo model, since I doubt I will need to manipulate them directly. Anyway, it's rather nice to see that the following views.py can generate the almost home page shown above:from django.http import HttpResponse
from django.template.loader import get_template
from mainapp.models import Section
def homepage(request):
seclist = Section.objects.all()
hpdict = dict(("secPathZone%d" % s.sechomeslot, s.secpath) for s in seclist)
return HttpResponse(get_template("homepage.html").render(hpdict))
This is neat, though I have an idea that rendering the unnumbered lists to add the missing link sets is going to involve me in a little more work than I have had to do so far. Still, it's an encouraging start. I am serving this web from a local Apache server using mod_python to control Django and serving static content (images, CSS files) directly.
November 29, 2007
Amazon Web Services
For the first time in a long time I have started to take a serious look at how the content for holdenweb.com is generated. The site is currently pretty much a testbed, and everything is generated from a database (even the occasional pieces of dynamic content, though most pages are simple static HTML). This allows us to ensure that all pages have a uniform style and that all the internal navigation links are consistent.
A couple of the content elements are generated programmatically. We create the Python news items by reading bookmarks I have tagged as python in my del.icio.us account (using methods to be described, I hope, in an upcoming Python Magazine article), and the books by searching for python using amazon.com's web services. Recent attempts to regenerate the content, however, have resulted in broken links to Amazon's site. Being Amazon they don't throw up an error page, they just try to sell you other products, but I don't want to piss our readers off with irrelevant links so I had to fix the code.
The issue causing the error turned out to be a change in the way that Amazon's site names its graphics files. When I first wrote the code all image names began with the product's ASIN (Amazon's product code), but now they get random-seeming names like 21rxsZ884SL.jpg. Since I was grabbing the leading digits and assuming that gave me the ASIN it's little wonder that the links were coming out wrong. During this effort I realized that I was using the API definition from November 10, 2004. Much to Amazon's credit the calls still work, despite the fact that the API seems to have been revised about twenty times since then.
The books have also become less relevant as more and more Monty Python content is issued, along with books about keeping snakes and the like, so I decided to hone up the search a little. It turns out that all I needed to do was add BrowseNode=5 to my request to limit it to computer and Internet books. Lo and behold, my test site is now populated with relevant literature, so after a few content tweaks I can republish the site and hopefully see the Amazon commission start to climb again. (Hope springs eternal). The new content probably won't be published until the weekend as there are a couple of other tweaks I'd like to make.
Since I was revising the code anyway I threw out the old expat-based parser and replaced it with code that used the friendlier ElementTree module, now a part of the Python standard library. This reduced the line count by about 35% and making it simpler, more robust, and easier to understand at the same time. I was quite amused to note that Amazon provide web service libraries for Java, C# and Visual Basic programmers. In Python the standard library already contains everything you need. We don't need no stinking libraries (though I am sure it would be easy to provide the same features that Amazon's libraries do from a Python library module).
Reading the updated specifications for Amazon web services has made me realize that there's a lot more you can do with them now than there was three years ago, so I shall be revisiting this topic before long. If you're doing neat things with Amazon and Python I'd be delighted to hear from you.
A couple of the content elements are generated programmatically. We create the Python news items by reading bookmarks I have tagged as python in my del.icio.us account (using methods to be described, I hope, in an upcoming Python Magazine article), and the books by searching for python using amazon.com's web services. Recent attempts to regenerate the content, however, have resulted in broken links to Amazon's site. Being Amazon they don't throw up an error page, they just try to sell you other products, but I don't want to piss our readers off with irrelevant links so I had to fix the code.
The issue causing the error turned out to be a change in the way that Amazon's site names its graphics files. When I first wrote the code all image names began with the product's ASIN (Amazon's product code), but now they get random-seeming names like 21rxsZ884SL.jpg. Since I was grabbing the leading digits and assuming that gave me the ASIN it's little wonder that the links were coming out wrong. During this effort I realized that I was using the API definition from November 10, 2004. Much to Amazon's credit the calls still work, despite the fact that the API seems to have been revised about twenty times since then.
The books have also become less relevant as more and more Monty Python content is issued, along with books about keeping snakes and the like, so I decided to hone up the search a little. It turns out that all I needed to do was add BrowseNode=5 to my request to limit it to computer and Internet books. Lo and behold, my test site is now populated with relevant literature, so after a few content tweaks I can republish the site and hopefully see the Amazon commission start to climb again. (Hope springs eternal). The new content probably won't be published until the weekend as there are a couple of other tweaks I'd like to make.
Since I was revising the code anyway I threw out the old expat-based parser and replaced it with code that used the friendlier ElementTree module, now a part of the Python standard library. This reduced the line count by about 35% and making it simpler, more robust, and easier to understand at the same time. I was quite amused to note that Amazon provide web service libraries for Java, C# and Visual Basic programmers. In Python the standard library already contains everything you need. We don't need no stinking libraries (though I am sure it would be easy to provide the same features that Amazon's libraries do from a Python library module).
Reading the updated specifications for Amazon web services has made me realize that there's a lot more you can do with them now than there was three years ago, so I shall be revisiting this topic before long. If you're doing neat things with Amazon and Python I'd be delighted to hear from you.
Subscribe to:
Posts (Atom)