Edgewall Software

Changes between Version 14 and Version 15 of TracPluggableModules


Ignore:
Timestamp:
Jan 13, 2005, 9:21:29 AM (18 years ago)
Author:
Christopher Lenz
Comment:

Status update

Legend:

Unmodified
Added
Removed
Modified
  • TracPluggableModules

    v14 v15  
    138138== Status ==
    139139
    140 I'm currently working on this code locally, and uploading tarballs as attachments to this page. The code is in prototype state, i.e. it is fully functional but is far from doing the stuff Trac can do. There isn't even database access yet.
    141 
    142 The tarball from 01/11/2005 has the following:
     140Previous snapshots of this code have been added as attachments to this page, but the "real" work has now started on the new [source:/branches/cmlenz-dev/rearch rearch branch]. That code is fully functional with the following exceptions:
     141
     142 * The mod_python handler and tracd are most likely broken, only way to use the branch is CGI.
     143 * Sessions won't work.
     144
     145What we '''do''' have:
     146
    143147 * A working plug-in system as described above, minus the configuration of which plug-ins are to be loaded.
    144148 * A new (and as of yet incomplete) abstraction layer between the Trac web-application and the web-server. Unlike the current {{{trac.core.Request}}} class, it provides separate request and response objects. It is based on [http://www.python.org/peps/pep-0333.html WSGI] with a simple adapter for CGI. ''This doesn't really have much to do with the plug-in system, it's just another refactoring that I'm playing with in the same sandbox.''
    145  * An interactive shell that allows testing the Trac web-app from the command-line (in {{{trac/web/testserver.py}}}).
    146149 * A new abstraction layer on top of the ClearSilver templating engine. It allows populating the HDF using native Python data structures such as lists and dicts.
    147150 * ClearSilver templating is a plug-in ({{{trac/web/clearsilver.py}}}), request dispatching is a plug-in ({{{trac/web/dispatcher.py}}}) and building the web-site chrome (e.g. the navigation) is another plug-in ({{{trac/web/chrome.py}}}). Hooking into HTTP authentication is also a plug-in ({{{trac/web/ext_auth.py}}}). The idea with the latter is that we could provide an alternative plug-in that would do form-based authentication.
    148  * Plug-in stubs for the ticket, changeset, timeline and search modules.
    149 
    150 For testing the code, you'll need a normal Trac 0.8 environment set up. The easiest way then is to use the interactive shell:
    151 
    152 {{{
    153 $ cd trac-pluggable_20050111
    154 $ PYTHONPATH=. python trac/web/testserver.py /path/to/projenv
    155 > import trac.web.clearsilver
    156 > import trac.plugins.timeline
    157 > get /timeline
    158 }}}
    159 
    160 That last command will simulate an HTTP request, and you should get the response printed to the console. To get the HDF of a response, type:
    161 
    162 {{{
    163 > get /timeline?debug=1
    164 }}}
    165 
    166 You can import any plug-in you want using the {{{import modulename}}} command, the plug-ins will need to be on the Python path of course.
     151 * A plug-in that runs the current set of modules in a compatability layer ({{{trac/plugins/compat.py}}}), providing them the environment they expect.
     152
     153None of the actual modules have been migrated to plug-ins yet, the all run under the compatibility layer. They will be migrated one after another in the next couple of days/weeks.
    167154
    168155To use the CGI, configure your web-server the same way as for a regular Trac instance. The CGI script is in {{{cgi-bin/trac.cgi}}} just like before. You will however need to add the following snippet to your [wiki:TracIni trac.ini] file:
     
    170157{{{
    171158[web]
    172 filters = clearsilver, chrome
     159default = compat
     160filters = external_auth, clearsilver, compat, chrome
    173161}}}
    174162
    175 (this determines the order of request filters, and it is important that the templating filter is the first to pre-process the request (and last to post-process it).
     163Here, ''default'' tells the request dispatcher which plug-in to use on a request to the root URL (i.e. {{{SCRIPT_NAME}}} without further {{{PATH_INFO}}}). It basically designates the welcome page. ''filters'' determines the order in which the request filters will be run (so yes, order does matter -- a lot).
    176164
    177165== Your Ideas Wanted ==