Changes between Version 1 and Version 2 of TracPluggableModules

Timestamp:

Nov 18, 2004, 10:46:36 PM (19 years ago)

Author:

anonymous

Comment:

Clean up random  characters.

TracPluggableModules

@@ -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.
 
-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.
+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.
 
 ''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 @@
 }}}
 
-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.
+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.
 
-''Renaming the current "{{{render}}}"Â to "{{{process}}}"Â here simply because the latter sounds more appropriate.'''
+''Renaming the current "{{{render}}}" to "{{{process}}}" here simply because the latter sounds more appropriate.'''
 
 == 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.
 
-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:
+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:
 
 {{{