Last modified 6 years ago Last modified on 08/29/11 15:36:18

Luci – Devel notes

This page aggregates various notes and links on various aspects of luci and underlying technologies. It is primarily dedicated to luci developers.

Note: Page is being updated continuously. - Last change: 2011-08-26



Currently, luci is based on !TurboGears2 meta-framework.



Considering python language, there are others notable frameworks:

Random links and discussion:

XHTML templates

currently powered by Genshi

  • web browsers workarounds (99% or more related to MSIE?)


synergy of static graphics, server-side (controllers, templates, ...) and client-side (JavaScript stuff) code

  • Luci's UI (and its evolution)
  • internationalization (i18n) / localization: Babel
  • basic UI components
    • flash !TurboGears2 built-in object (webflash package)
    • flash2 module (own work)
      • implemented specially for the purpose of this project (although it is universal enough) to avoid the restrictions of flash module, based on post in TurboGears discussion group
      • is able to display unlimited number of messages per response and can be better handled on the templates side (incl. ability to hide message in a cool manner utilizing JavaScript?/framework effects)
      • for the usage see doc comment for Flash2 class in luci.lib.flash2
  • GUI consistency and other guidelines
    • modal dialogs are 520px wide
    • names and ids should be chosen wisely, especially in the forms (see DOMLint)

Client-side logic

JavaScript + jQuery + jQuery UI

Server-side logic

controllers together with internal and external components

Server-side data

a range of options from the most persistent to the most volatile

note 1: thread-safety refers to the state that if you access and manipulate with some object while processing one request, it doesn't affect the object that you access the same way while concurrently processing another request

note 2: cache layer in !TurboGears2 middleware stack not covered yet

  • DB layer
    • data scope: completely persistent data shared within the whole application (can also be shared between different instances of application, but not probably if they all are running at the same time)
    • thread-safe object/data altering: yes (at least from definition of DBMS)
    • TBD in more detail
  • sessions: Beaker
    • data scope: automatically managed persistent data tied with particular sessions, but without auto-removal after the session ended
    • thread-safe object/data altering: presumably yes (if it is supposed that session = max 1 request handling at the moment)
    • the data reside in the location given by beaker.session.data_dir in application's ini file and might be cleaned on demand without any serious consequence (otherwise this can waste noticeable amount of space after being used for a long time)
    • on client's side, there is a cookie identifying the session, this cookie is set to be cleaned with the close of a browser (expiration can be redefined)
    • covered in TurboGears2 doc, Pylons doc
    • Beaker homepage: (documentation, sessions from p.5)
  • globals for the whole application
    • data scope: volatile data shared within the whole application and existing only in run-time
    • thread-safe object/data altering: presumably no (locks have to be utilized when multiple access can happen)
    • for this purpose, there is app_globals global variable offered by !TurboGears2 which can be initialized/pre-filled with data in luci.lib.app_globals module
  • globals defined in imported modules
    • data scope: volatile data shared within the whole application (in modules where imported) and existing only in run-time
    • thread-safe object/data altering: no (locks have to be utilized when multiple access can happen)
  • thread/request local storage/globals
    • data scope: volatile data existing during request handling
    • thread-safe object/data altering: yes
    • for an object which should have only one instance per thread/request at most, paste.registry module can be used
    • for other values, there is tmpl_context global variable offered by !TurboGears2
  • controllers' locals
    • thread-safe object/data altering: yes
    • these are the most volatile data units and their scope works as expected

Technical services

Handy tools for code development/improvement


Manual tests and checks

Automated/unit testing


Context of cluster product, standards-compliance, etc.

TBD: identifiers/values restrictions (against RelaxNG etc.), ...

~+See also+~