Changes between Version 18 and Version 19 of TracPluggableModules

Timestamp:

Apr 11, 2005, 5:15:59 PM (19 years ago)

Author:

anonymous

Comment:

—

TracPluggableModules

@@ -125 +125 @@
 
 A couple of drawbacks become visible here:
- * 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.''
+ * 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 losing its efficiency.''
  * Similarly, ordering of the events will need to be done in Python in the timeline module after it has collected all events. ''See above.''
 
@@ -219 +219 @@
 
 ''James, the idea I was trying to get across with this proposal is that modularizing the current core of Trac, while allowing the mechanism to be used for plugging in new or custom functionality, would probably be easier and than developing a well designed plug-in interface, '''and''' come with more benefits.'' --ChristopherLenz
+