Bring out the g33k
{ Category Archives }
In this part of the series we’re going to take a step back from SQLAlchemy and have a look at making the user experience a little more fluid. We’re going to convert all our hand-coded forms to widgets, and we’re also going to use widgets as a display mechanism.
Welcome to part 3 of the SimpleBlog series, where we shall be looking at SQLAlchemy’s many-to-many relationships.
Since the end of part 2 I have done some work on the “admin” side of things with a way to create posts and comments via a web interface rather than tg-admin shell. While I’m sure that asking your visitors to log in via SSH and use the shell would have gone down well, I think that this way is a little easier. :)
You can download the code from here. Continue Reading »
Recently, pastebin.com has been having performance issues and I’ve been struggling to find an alternative that does syntax highlighting in enough languages to satisfy my needs. I tend to sit in #turbogears a lot and help people new to TurboGears when I can and a pastebin is invaluable in that situation.
From this need, Stickum was born. It’s a very simple TurboGears application that accepts pastes and… well, pastes them, and it does syntax highlighting for a variety of languages so it’s not just for Pythonistas.
In our last adventure we created the skeleton of a simple blogging application using SQLAlchemy as the ORM. In part 2 we are going to look at using Foreign Keys and create a method of allowing comments.
If you need the simpleblog files from the end of Part 1 they can be found here.
I’ve noticed a lot of people asking questions about SQLAlchemy in the #turbogears channel on Freenode and the TurboGears mailing list, and there aren’t that many step-by-step tutorials in using TG and SA so I decided to write one.
The tutorial will be published in two sections; Part 1 will cover the basics and part 2 will extend part 1 to cover a few of the trickier aspects of creating a project with SA.
I came across a use case where I needed to disable users without actually deleting them so a user could continue to be associated with their data and reinstated at a later date.
At first I thought that I’d need to roll my own Identity Provider but I came up with a method that is slightly easier to implement.
I added a BoolCol to the auto-generated TurboGears User Class:
Class User(SQLObject):
...
disabled = BoolCol(default=False)
...
I then changed the classmethod that SOProvider uses to get the user from the database to raise an SQLObjectNotFound when a user’s “deleted” flag is set to True.
@classmethod
def by_user_name(self, text):
try:
u = self.by_email_address(text)
except SQLObjectNotFound:
raise
if u.disabled:
raise SQLObjectNotFound
else:
return u
Note that this classmethod has also been modified to return users by email address.
This way user can effectively be disabled as they can no longer log in successfully. It’s cheating outrageously because raising an SQLObjectNotFound exception is clearly lying to the SOProvider, but it works effectively.