Team meeting 6/22/2011


Agenda 6/22/11

Pushing and pulling (git), deploying to server

Learning code and web programming
  • Read later chapters in Django book - read the whole thing
  • Documentation on Django website is a reference

Event viewer (Noam, Jimmy, review)
  • Jimmy will work on that
  • Check permissions before displaying fields in template code

    {% ifagentcan 'view Item.name' event %}
    {{ item.name }}
    {% else %}
    YOU CANNOT VIEW THIS FIELD
    {% endifagentcan %}

Diff displayer' (Mike, Noam)
  • Noam found HTML diff viewer that is open source: HTLMDiffs.py
  • Model view separation?
  • HTML is harder than plain text so need to go with what is available

Email integration (deliverable due June 30)
  • Will include diff display
  • Firewall issue on Deme website not an issue for AIR specifically - can't send to outside addresses
  • Need to edit template for email deme_django/cms/templates/notification/
  • four types of notif messages discussed and agreed upon

List viewer proposal

Symsys website - spam, slowness, code push (Chris, Mike, Joe)
  • performance problems may be due to virtualization - Ubuntu standard (KVM) in use now, but everyone else uses Xen or vmware
  • Also may be due to database not being able to fully reside in memory
  • Chris may copy Symsys databse to his laptop and see how fast it runs, profile performance, work with Mike to get started
  • Chris will do research and take on moving to the cloud: 4 servers are PIECE ($40/mnth on Linode), Whovoted (under $20/month); keep Deme and Symsys on our box; entire machine would cost about $200/month
  • Todd and Chris will talk about integrating alumni database with spreadsheet data

Issues document (and Mike's local todo document) - create project tool?
  • Mike recommends using Git plaintext document instead - committing a text file there
  • Synchronous and asynchronous editing with notice to users seeing users - synchro is harder because can't use TinyMCE, and how do we store versions with synchro editing
  • Jimmy will create new Git document in repository for issues, migrating and organizing issues in Deme Issues, placing link item in Deme Team Folio to replace current Deme Issues document, merge with Mike's old document in repo

Report on yesterday at CMU-SV (Todd)
  • Possible empirical studies this summer with Jimmy

Mike webcast to everyone to explain Deme plumbing (including permissions)


Noam's Git Hub Notes

Usual path of updating the github
git pull
python manage.py migrate
git status
git add
git status
git commit
git push

TO UPDATE THE ACTUAL WEBSITE:
ssh nbenavi@deme.stanford.edu
password: 

to add another user 'sudo adducer jtobin1'

to make an update
cd /var/www/deme/deme_django/
sudo -u www-data git pull
maybe a migrate


sometimes restart apache
if changed py
sudo /etc/init.d/apache2 restart

sudo su - mike (logs in as mike)
history (displays my history)

screenshare

PIN: 479167

www.yuuguu.com/share




Settings.py

This is used for webmasters.

Mike has added a few methods:

# The hostname used in URLs sent by email                                      

DEFAULT_HOSTNAME = 'localhost'

 

# The hostname from which notification emails are sent                          

NOTIFICATION_EMAIL_HOSTNAME = 'localhost'

 

# Enable if you want Deme to check permissions (highly recommended)            

ENABLE_PERMISSION_CHECKING = True

 

 

URLs

List of regular expressions for what the urls can be and what they do.

Modules can make urls that take precedence over cms urls.

If we open cms/urls that is going to get most of the urls and map them to the right place. There are three regular expressions: item-type, item_url (having an id in the url), and alias view (where viewer requests urls are)

Viewer request urls are urls that map to a page such as /contactus would map to a item_url. Basically an alias.

Every url goes to one of those three methods as dictated by the regular expressions. The methods are in cms/dispatcher.py

Dispatcher.py

They get the different variables from the url itself. viewer_

Deme.stanford.edu/viewing/item/21/show.html

name = kwargs['viewer']  =item

    action = kwargs.get('action') = viewing

    noun = kwargs.get('noun') = 21

    format = kwargs.get('format') = show.html

 

item_view takes in a requests and figures out the different parts (as above) then creates a python class then if it exists we init it for http. We then return the http response. All the rendering is done in this code.

We want to create a viewer instead of a django view. Our version of a viewer is a class and we can use object oriented inheritance.

Viewers live in cms/base_viewer.py

 

The main class is called viewer.

First dispatcher calls initforhttp (sometimes we’re not coming from an http request sometimes people want to embed into an email). From the request we get stuff from the request. We get the context, which is a key valued dict in python. All the template variables come from self.context

All django templates have a context that is defined in the viewer.

If you want to display anything in a template you must have it in the context first.

READ THE ARCHITECTURE on deme docs

For Internet Explorer users: Click on the Tools menu, located at the top of your browser window. When the drop-down menu appears, select the option labeled Full Screen.

For Chrome users:Click on the Chrome "wrench" icon, located in the upper right hand corner of your browser window. When the drop-down menu appears, select the choice labeled Full Screen.

For Firefox user:Click on the View menu, located at the top of your browser window. When the drop-down menu appears, select the option labeled Full Screen.

For Safari users: Safari currently does not support the ability to go fullscreen.