Basic functionality provided by QP

QP, or quantum placet, latin for as much as you please, is a young but stable framework, benefiting from the several years of experience of its tried and tested predecessor, Quixote. QP provides most of what one expects from a high-level web framework in this technical essay:

  • Mature request/response classes
  • Cookies and other HTTP headers
  • Flexible URL dispatching
  • Forms
  • Unicode templating, using QPY
  • Crumbs and menus
  • Error handling and Logging
  • Multi-process HTTP/SCGI server
  • Multi-site management
  • Users and Sessions
  • Authentication
  • A Permissions model

The last 3 features depend on a database — by default, QP assumes that the Durus object database is being used for persistence. Using Durus, these database-dependent features work out-of-the-box.

In addition to these functionalities, that one tends to expect from a high level web framework, QP provides other features and innovations that are maybe less known but all the more intriguing:

  • The simple RespondNow pattern, to break out of path traversal.
  • The spec validation module.
  • Customizable URL traversal, with hooks _q_traverse() and _q_lookup() at every component. This flexibility facilitates the design of RESTful URLs and applications.
  • Possibility to use any template system, easily.
  • Possibility to run QP without a database, or with any database. This forfeits the out-of-the-box Durus-dependent features, mentioned above, however the DB interaction API required to achieve same with a different persistence layer is small.
  • Possibility to customize the entire handling of the response to each request, by overriding the Publisher.process_hit() method (a Hit holds a request and a response).
  • Pythonic conceptual integrity, that may be crudely translated to mean no magic and no bloat.

And, many other simply delightful QP features waiting to be discovered!

Leave a Reply

Your email address will not be published. Required fields are marked *