Steven Osborn

Tagged: Google App Engine RSS

• 

  steve918 8:38 am on April 11, 2008 Permalink | Reply
  Tags: Django (7), Error pages, google (5), Google App Engine, Goolge App Engine, Python (8)   

  Custom error pages in GAE/Django 

  To allow for custom error pages (404,500) in Django/Google App Engine all you need is this bit of middle-ware that stubs out the request class for you so that it doesn’t blow up.

  Add your custom templates to your template directory and name them 404.html, 500.html etc.

  Paste the following into middleware/errorpages.py

  class DummyUser(object):
  
      def get_and_delete_messages(self):
          pass
  
  class NeedsUserObject(object):
  
      def process_request(self, request):
          request.user = DummyUser()
  

  In your settings.py add the NeedsUserObject middleware

  MIDDLEWARE_CLASSES = (
    ...
      'middleware.errorpages.NeedsUserObject',
  )
  

  foo is discussing. Toggle Comments

   
  • 

    foo 2:53 pm on September 18, 2009 Permalink | Reply

    Thanks:) works great.

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site

  Notify me of follow-up comments via email.

  Notify me of new posts via email.

   
• 

  steve918 11:54 pm on April 10, 2008 Permalink | Reply
  Tags: Django (7), google (5), Google App Engine, Python (8)   

  Django manage.py wrapper script for Google App Engine 

  I’m used to running mange.py in my Django apps and I kept forgetting the name of the Google App Engine equivalents. My script only knows how to do two things at the moment, “runserver” and “publish” but now I can manage everything the way I’m accustomed to.

  Update: Aprill 11 – Added toggle_debug, automatically switches debug off when publishing and back on for development.

  #!/usr/bin/env python
  #
  # Simple convience script for common publishing and develop tasks
  # This script expects dev_appserver.py to be in your $PATH
  import os, sys, re
  
  def main(argv):
  
      command = ""
  
      try:
          command = argv[1]
      except:
          usage()
          exit(2)
  
      if command == 'publish':
          publish()
      elif command == 'publish-debug':
          publish(True)
      elif command == 'runserver':
          runserver()
      elif command == "--help" or command == "-h":
          usage()
          exit(0)
  
  def usage():
      print """
      Usage: python manage.py [command] 
  
      Commands:
          publish - 'updates' Google App Engine with your current version
          publish-debug - 'updates' Goolge App Engine with debug turned on
          runserver - launches the development server on port 8080
  
      Options:
          --help, -h - Prints this screen
  
      For more information on a particular command, run [command] --help
      """
  def get_gae_dir():
      """ Locate dev_appserver.py and return the directory is in. """
  
      # There's probably a smarter way to do this...
      script = 'dev_appserver.py'
      stdin, stdout = os.popen2('which %s'%script)
      xpath = stdout.read().strip()
      stdout.close()
      stdin.close()
  
      # If the file is a symlink, find out where the actual file lives.
      try:
          tmpdir = os.readlink(xpath)
      except OSError:
          tmpdir = xpath
  
      return os.path.abspath(os.path.dirname(tmpdir))
  
  def toggle_debug(status):
      st = 'False'
      if status:
          st = 'True'
  
      os.rename('settings.py','settings.py.bak')
      orig = open('settings.py.bak').read()
      p = re.compile('DEBUG\s=\s(True|False)')
      n = p.sub('DEBUG = %s'%st,orig)
      nw = open('settings.py','w')
      nw.write(n)
      nw.close()
  
  def gae_parent(script):
  
      DIR_PATH = get_gae_dir()
      DEV_APPSERVER_PATH = os.path.join(DIR_PATH,'google/appengine/tools/%s'%script)
  
      EXTRA_PATHS = [
        DIR_PATH,
        os.path.join(DIR_PATH, 'lib', 'django'),
        os.path.join(DIR_PATH, 'lib', 'webob'),
        os.path.join(DIR_PATH, 'lib', 'yaml', 'lib'),
      ]
  
      sys.path = EXTRA_PATHS + sys.path
      execfile(DEV_APPSERVER_PATH, globals())
  
  def publish(debug=False):
  
      if(debug):
          toggle_debug(True)
      else:
          toggle_debug(False)
  
      sys.argv[1] = "update"
      try:
          sys.argv[2] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
      except IndexError:
          sys.argv.append(os.path.abspath(os.path.dirname(os.path.realpath(__file__))))
  
      gae_parent('appcfg.py')
  
  def runserver():
      toggle_debug(True)
      sys.argv[1] = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))
      gae_parent('dev_appserver_main.py')
  
  if __name__ == '__main__':
      main(sys.argv)
  

  Django Google App Engine Snippets « Hone Watson Bookmarks is discussing. Toggle Comments

   
• 

  steve918 6:57 pm on April 9, 2008 Permalink | Reply
  Tags: Django (7), google (5), Google App Engine, Python (8)   

  Google App Engine Limitations 

  I’m really digging the concept that is Google App Engine, but I think they a little bit of work to do before I would be willing to put any effort into porting to their platform. Their marketing points for this include the fact that it allows you to build, deploy and iterate your application quickly, but the fact that I have to now port just about every Python library out there to use BigTable and URL fetcher is a serious productivity loss.

  • Python Only – This doesn’t bother me, but is still a deal breaker for a lot of people.
  • No way to schedule tasks. (cron)
  • No way to dynamically route subdomains. You can’t point *.yourdomain.com at a single script. So your urls have to look like example.com/tulsa and not tulsa.example.com
  • You can’t use any existing libraries that make network fetches. Google forces you to use their URL Fetcher class. Which is broken in several ways:
    • No way to set timeout
    • No HTTP Auth Support
    • Does not follow redirects
  • You have to user BigTable for your Database Layer, so you have to port any existing database code you have. There is also no ORM for Django to use BigTable yet, which means Django Admin interface will not work.

  On the bright side, their publishing and versioning process is outstanding. The administration interface is pretty sexy so I’ve take quite a few screen shots for anyone who didn’t get an invite and would like to see it.