Changes between Version 5 and Version 6 of TracPluggableModules
- Timestamp:
- Nov 19, 2004, 10:22:53 AM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracPluggableModules
v5 v6 35 35 There needs to be a central facility that manages the discovery and loading of plug-ins as well as the communication between them. We'll call this the {{{ModuleManager}}} for now. 36 36 37 The module manager should probably be part of the environment, or in other words, for any environment their should be one module registry. Module discovery would presumably be based on a given paths (list of directories) that contain python modules. The registry class would find all classes that somehow identify themselves as Trac modules (for example by sub-classing a central {{{Module}}} 37 The module manager should probably be part of the environment, or in other words, for any environment their should be one module registry. Module discovery would presumably be based on a given paths (list of directories) that contain python modules. The registry class would find all classes that somehow identify themselves as Trac modules (for example by sub-classing a central {{{Module}}} class, or by defining some module-scope variable). There could also be a 'plugins' folder in Trac environments that would be added the path by default. 38 38 39 39 ''An alternative and possibly more efficient but also more cumbersome approach would be to require the user to specify the "fully qualified" name of every additional module, for example in TracIni. Modules such as the timeline would be in the list by default, but could be disabled by removing them.'' … … 60 60 }}} 61 61 62 In an environment such as [wiki:TracStandalone tracd] 62 In an environment such as [wiki:TracStandalone tracd] or [wiki:TracModPython mod_python], the {{{process}}} method might be called concurrently on the same module object, so module implementations should not store request-specific data as instance variables, but rather pass such data through as parameters to other methods. 63 63 64 ''Renaming the current "{{{render}}}" to "{{{process}}}"here simply because the latter sounds more appropriate.'''64 ''Renaming the current "{{{render}}}" to "{{{process}}}" here simply because the latter sounds more appropriate.''' 65 65 66 66 == Module Cooperation == … … 86 86 The wiki module would contribute to the timeline simply by appropriately implementing these functions. Same for any other module that wants to put events in the timeline. 87 87 88 The timeline module would use a convenience function in the {{{Module}}} 88 The timeline module would use a convenience function in the {{{Module}}} base class to collect the events from all available plug-ins. That might look like the following: 89 89 90 90 {{{ … … 97 97 98 98 A couple of drawbacks become visible here: 99 * The current timeline code is very efficient by basically consisting of a single SQL query over all the related tables. Under the plug-in model, we'd have at least one query per contributing module. 100 * Similarly, ordering of the events will need to be done in Python in the timeline module after it has collected all events. 99 * The current timeline code is very efficient by basically consisting of a single SQL query over all the related tables. Under the plug-in model, we'd have at least one query per contributing module. ''Not necessarily: each contributing module could contribute the appropriate SQL fragment for the query, as well as a post-processing routine. The current timeline code could be easily refactored that way, without loosing its efficiency.'' 100 * Similarly, ordering of the events will need to be done in Python in the timeline module after it has collected all events. ''See above.'' 101 101 102 102 This is probably just the price to pay for a cleaner architecture, but optimizations may be possible. … … 114 114 Comments, alternative approaches, constructive criticism, etc. Bring it on! 115 115 --ChristopherLenz 116 116 117 117 118
