Monday, February 22, 2010

UH Dorm Energy Website: Pinax Style

I decided to go with Pinax for creating the UH Dorm Energy website. Since removing Pinax apps can be kind of a pain, I started by cloning the CMS project and built up from there. And in my short experience with it, I'm beginning to think that it is the better way to go.

Pinax uses a wide collection of plugins from the Django community along with some extra tweaks. For example, the blocks of text in the CMS are managed by a Django app called django-generic-flatblocks. With this plugin, one can lay out the blocks on the page and then use the admin panel to change the content (which can be images, text, or whatever else you want). However, you don't really want to go back and forth between the admin panel and the page to see if the content is just right. So Pinax added some additional jQuery Javascript to allow an admin to edit the content within the page. Once the content is changed, the page is refreshed to show the admin the results of their change.

Editing some text within the Kukui Cup page.

I created individual pages for the different tabs and started laying out the blocks. After about an hour or two, I reproduced most of the pages in the set of mockups. There's still some work to do as some styles may need to be changed. However, for the most part, the layout is there.

Mockup of the front page in Balsamiq.

Reproduction of the front page using Pinax

Of course, we don't need everything that Pinax has. I replaced the login functionality in Pinax with django-cas, a plugin for CAS authentication. I used that to login and logout with our UH usernames. It works fairly well out of the box and didn't require any additional setup. I still kept the Pinax login, which could be useful when I'm testing the different user roles.

I have something that looks okay, but it still needs a little bit more work. My next tasks are to continue mocking up the user page and to start creating some Django apps for the functionality that we need.

Monday, February 15, 2010

Diving Into Django

After our previous milestone, I decided on a little change of pace. I was feeling okay with Elgg, but I wanted to see if I could get something done using a different framework. I've been meaning to learn a little Python and I know people who have used the Django framework. To start, I began researching Django tutorials and plugins.

First, I went through a few tutorials on Django, including the one in the Django documentation. Coming from a Rails background, I noticed quite a few differences. First, there aren't that many generated files. Rails creates quite a few folders and files when you start a new project. However, the django-admin.py script only creates a few Python files. Which is okay as long as I don't need to dig through the Django install to change things. If all of the things I need are in my newly created app, that's fine.

I guess the real difference is simply that there's more configuration in Django. A templates folder is neither created nor required unless you change the settings.py. Even after an app (as in the plugin within your Django web app) is created, it is not used until it is added to the INSTALLED_APPS field of the settings.py.

After going through these short tutorials, I know I've only scratched the surface. I borrowed a book from a friend and we have another book on order from Amazon. Going through those books should help me get more comfortable with Django.

I did some tinkering around with two Django based applications: Pinax and Django-CMS. I was interested in Pinax because they tout themselves as being an easy way to get started quickly. I found that when you start a Pinax project, you do get a pretty functional interface. However, I was a little soured on it because adding and removing the included apps was kind of a pain. There is some template file in the Pinax code that needs to be changed when I remove an installed app. There's probably some work around

Django CMS was a little tricky to set up especially with some of the recommended software (like reversion and south). Once I got it working, I found that at least the admin site works like any other Django site. Django CMS does not come with any out of the box templates though, so I need to create my own template files. Not ideal for getting started right away.

Pinax seems like the obvious choice for getting started right away. But if I can create some decent templates in Django-CMS, then that could be a viable alternative.

Time to flex them Pythons!

Monday, February 8, 2010

Drive By Elgg-ing



We are approaching the first milestone and the Elgg implementation of the Kukui Cup is in a pretty good state. Some of the things we set out to do for this milestone was to get commitments and actions going, get a Google Gadget inserted, and figure out a way to do CAS authentication. I'm happy to say that most if not all have been implemented.

Commitments and actions are supposed to be things a user can do to earn points in the dorm energy competition. They can be things that promote energy literacy like watching videos or making sure the lights in the common room are off if no one is there. Users should be able to commit to an commitment or action and have it posted on their profile. However, only admins can create them.

Creating a commitment in the admin interface.

List of actions

Getting a Google Gadget inserted was a little tricky. Something in the Elgg engine kept redirecting when I inserted the code into the HTML. Fortunately, there's an Elgg plugin called Xgadget that creates a widget. Right now, a user adds the widget to their profile and inserts the Google Gadget code. What we want is some widgets that contain pre-defined Google Gadget code. In a future revision, this can hopefully be fixed.


Xgadget widget with a Google Calendar embedded.

CAS (Central Authentication System) login for UH was another difficult feature. Ideally, we'd have the UH login system handle the username and password stuff so that we don't need to track it. Fortunately, there's a plugin for this as well! The cas_auth and ldap_auth plugins work together to log the user in. I'm able to successfully log in with my UH username and password. However, there was one little catch. Student directory listings are private and are unaccessible via LDAP. Thus, a student would currently be unable to use this system. We'll need to look into that in the future.

Login page with tiny CAS connection button

Finished user profile page.

About the next milestone, I'm considering making a switch to using a different framework. I've been wanting to look into Django for a while. There's a module called Pinax that'll add a lot of social networking functionality to the site. As soon as tomorrow's presentation is over, I'm planning on checking it out. We'll see if it's any better than Elgg.

Monday, February 1, 2010

Elgg Me On

This week was continuing work on Elgg. After my last blog, I got it to a state where it looked like the mockups provided to us at the beginning of the semester. It was also somewhat functional. Admins can create commitments and actions for the users to take and messages could be posted to each person's profile. I even put in a simple Javascript function to count down from 10 to 0 to simulate the real time use.

"Complete" profile view as of last week.

What has helped me get this far are the plugins that come with Elgg. It's not the functionality of these plugins. Rather, it's the source code for the plugins themselves. For example, I wasn't sure how to make sure only admins were allowed to create commitments and actions. I took a look at the source of the default widgets plugin, which allows admins to define what widgets are automatically added to a user's profile or dashboard. By looking at the default widgets initialization script, I figured out how to add links to create commitments and actions in the admin interface.

Admin interface for creating a new commitment

Of course, there's a good amount of fakery in "version 0.01 pre-alpha". The created commitments and actions automatically belong to the user who created them. While it looks good as a fake interface, that's not how the actual application is going to be. I had tried to avoid going deep into Elgg, but since I'm working on this again this week, I might just have to.

Even at this point, I'm still wrapping my head around how the data in Elgg is arranged. I wasn't sure how to create an object like a commitment and have multiple users be associated with it. While poking around the source code, I did stumble on a function that creates relationships between two Elgg objects. So I think I can put together some kind of interface for next time. Source code to the rescue!

The lack of detailed documentation is kind of a bummer, but having the source code helps a lot (the API can be useful too if you know what you're looking for). And from what I can tell, the community is fairly active. I haven't had to ask them any questions yet, but Philip did suggest that I ask a question to gauge their response time. Just haven't thought of a good question to ask yet.

So, in short, my tasks for this week and next are to implement the commitment/action workflows, create a widget for an arbitrary Google Gadget, implement the default index page, and remove some extraneous features that we probably don't need. And we'll see how it goes from there.