Clone wiki

CATweasel / Home

Dead project

This project ist pretty much dead. I'll leave it here for documentation.

See the Roadmap for versions and changelog.


If you would like to contribute or comment to the development of CipUX or CATweasel you can can to so on the CipUX mailinglists.

UI Mockup

Currently we are in the process of developing the new user interface. See UIMockup for more information. Perhaps you find something worth nagging or contributing.


CATweasel is an alternative to CipUX CAT-Web based on Django, a Python web development framework. Like CAT-Web itself CATweasel uses the XML-RPC interface to communicat with CipUX.

Right now CATweasel is just a prototype. So don't expect to get production ready quality. Even some things on the API-Level will likely change. But it is planned to get the first stable release this year.



If you want to test drive CATweasel you'll need the following things:

This is everything you need for deveopment. If you intent to set up a production ready envirenment you will also need an apache with mod_wsgi installed.

For Development

1. Clone the repository:
$ hg clone
2. Change the settings in

If you just cloned the repository you won't have the but an example. So just rename the and change the IP for RPC_SERVER_URL. Since you are running CATweasel on your local development machine this will likely be

RPC_SERVER_URL is the IP of the server your CipUX is running on. Don't change the port and path. They will likely be the same.


# Might look like this
3. Check out the JS part for some of the built-in modules

You don't really need that step for development, but most of the built-in modules won't work if you skip this step.

Got to the catweasel-client-ui repository on bitbucket and follow the instructions in the wiki.

4. Fire up the Application Server

Now cd back to the project root. Here you will have to create a directory named db to store the sqlite database CATweasel needs to remember session information. After that we will use the manage script to create the database. The manage script will ask you if you wish to create an admin account. Just answer "no".

mkdir db
./ syncdb

After all that is done, we can start the application server. Again we use the manage script.

./ runserver

Now the server should be up and running on If some settings are missing or other things went wrong it will tell you.

Now open your browser and navigate http://localhost:8000. You should automatically be directed to the login screen. There you can login with "cipadmin" as username and "geheim" as password. There are nearly no modules implemented right now, so don't expect to see too much. Remember, this is still an early version. But a listing of teachers and students is there to give you glimpse.

For Production

See ProductionEnvironment

Module Creation

Right now the module creation consists of four steps. CipUX task implementation, VT creation and registration of the module in the module config. You might now wonder what VT means. VT stands for views and templates. A little excursion. Django is a MVT based framework. The M in MVT stand for model - luckily you won't have to deal with the models. So we have models, views and templates. This concept is very similar to the more popular MVC concept. In django the view is what MVC calls the controller and the template is called view. So in the last step you will have to implement the views and the corresponding templates.

1. CipUX Task Implementation

The task implementation is rather easy. In the directory cip_rpc you can find the file All available tasks are defined here as methods and registered as a task.

# cip_rpc/

def cipux_task_sum(self, sum1, sum2):
    pay_hr = {
        'header_hr': self.header_hr(),
        'login': self.username,
        'cmd': 'cipux_task_sum',
        'param_hr': {
            'summand1': sum1,
            'summand2': sum2
        'ticket': self.ticket,
    return self.task(pay_hr)
# Register the task.    

There a basically two things you have to take care off:

1. Do you need parameters for this task? If so make sure the method accepts the parameters and they are passed to CipUX in param_hr.

2. Make sure you don't make up tasks CipUX won't support. You can get a list of the tasks with the command "cipux_task_client -l <query>".

Mostly the rest of the method will be the same all the time.

2. VT Creation

View and template creation might be the biggest challenge if you want to create a module. For a deeper understanding you can - again - take a look at the django documentation.

The views. Every view can be found in "cip_modules/views". To see a sample implementation take a look at Here you can see the "actions" that might happen in the module. Create, read, update, delete and the more special cases list and new. As you might have guessed this sounds very much like a RESTful implementation. So indeed only this actions will be exposed by the system and you can only implement those. Other action will be there but you can't send a http-request to them. can show you the URL patterns known to the system:

$ ./ showurlpatterns
[[<RegexURLPattern None ^teacher/$>],
 [<RegexURLPattern None ^teacher/list/$>],
 [<RegexURLPattern None ^teacher/new/$>],
 [<RegexURLPattern None ^teacher/create/$>],
 [<RegexURLPattern None ^teacher/(?P<id>\w+)/$>],
 [<RegexURLPattern None ^teacher/(?P<id>\w+)/(?P<action>\w+)/$>],
 [<RegexURLPattern None ^student/$>],
 [<RegexURLPattern None ^student/list/$>],
 [<RegexURLPattern None ^student/new/$>],
 [<RegexURLPattern None ^student/create/$>],
 [<RegexURLPattern None ^student/(?P<id>\w+)/$>],
 [<RegexURLPattern None ^student/(?P<id>\w+)/(?P<action>\w+)/$>]]

With step three (Module Registration) finished your module with appear in that listing too. Right now CATweasel just doesn't know which URL to take for your module.

It might be best, to just take the basic structure of existing views and start implementing own functionalities. The names of the actions have to be the same anyway.

The templates. The corresponding templates to a view can be found in "cip_modules/templates/<name_of_the_view>". Again, take a look at basic_object. You will see, that nearly all the "actions" have their template. Only create is missing, since normally you don't need a special view after an object is created. For a better understanding of the django template language see the documentation.

3. Module Registration

The only thing left to do is the registration of the module. This is very easy and just a matter of a few minutes. In "cip_modules" you will find the modules.cfg. It is a simple ini-style config with three values: name, icon and html_path. The name is the text that will be displayed in the module overview, icon is the path to the graphic shown in the module overview and html_path is used by CATweasel to create the URL patterns seen above in "2. VT Creation". E. g.:

# cip_modules/

name = teacher
icon = img/senior.png
html_path = /teacher/


Right now everything defaults to english. If you want to translate CATweasel follow this documentation.

An empty po file for german translators can be found here.




Don't hesitate to contact use if you want to contribute!

Have fun!