Changes between Version 6 and Version 7 of TracPluggableModules

Timestamp:

Nov 20, 2004, 11:59:50 AM (19 years ago)

Author:

cboos@…

Comment:

Contribute idea: link to TracObjectModelProposal , module configurability and Client interfaces

TracPluggableModules

@@ -69 +69 @@
  * contribute functionality to other modules
  * provide hooks so that other modules can contribute to its functionality
+
+=== By using Function Hooks ===
 
 The supporting model for such cooperation between modules should be functions defined by the contributing plug-in, and called by the plug-in to which we contribute. For example, let's assume the timeline module documents the following hook functions (or ''extension points'' in Eclipse jargon):
@@ -102 +104 @@
 This is probably just the price to pay for a cleaner architecture, but optimizations may be possible.
 
+=== By using ExtensionPoint Interfaces ===
+
+Alternatively, a Module could define one or
+several client interfaces (all ExtensionPoint
+subclasses), and the other modules could provide zero, 
+one or more implementations for this Client interface.
+
+This approach would provide both clarity and flexibility
+(if not even a simpler programming model) than the 
+''hook functions'' approach.
+
+See a more detailed description below
+'''Your Ideas Wanted / Modules and Configurability'''
+
+
 == Other Aspects of Plug-Ins ==
 
@@ -115 +132 @@
 --ChristopherLenz
 
+=== Trac Modules and Trac Objects ===
+
+The approach of Pluggable Module described here
+would be complementary to the Trac Objects idea
+described here: TracObjectModelProposal.
+
+--ChristianBoos
+
+=== Modules and Configurability ===
+
+In some cases, one would like to have a fine control
+on how a module works. I'll take an example.
+The Timeline module interacts with the Ticket module.
+The latter provide several timeline entries to be
+displayed by the former, as well as specific filters
+for composing the filter panel.
+
+But let's say I would be interested in having
+the Ticket Contributions displayed (See #187 and my
+patch at #890), whereas others wouldn't want this
+option to be available. How to solve this?
+ * Subclassing the Ticket module? 
+   (For the ''hook function approach'': not very 
+   flexible, what if there are multiple optional 
+   features)
+ * A configuration flag for the Ticket module?
+   (This would be more flexible, but, well, would be 
+   spaghetti code in the end!)
+ * Have the Ticket module provide a (configurable) list 
+   of !TimelineEventProvider objects (the, or one of the 
+   ExtensionPoint interface that the Timeline module 
+   would offer)?
+
+The last idea seems the most interesting.
+The Timeline module expects that the 
+other modules will provide zero or more
+!TimelineEventProvider object.
+
+The Ticket module would implement all of the following subclasses of !TimelineEventProvider class:
+ * !NewAndCloseTicketsInTimeline
+ * !ReopenedTicketsInTimeline
+ * !TicketContributionsInTimeline
+
+After being configured (either from the {{{trac.ini}}}
+file, or any other mean, even dynamically!), 
+the Ticket module could decide which instances of 
+these subclasses will be given to the Timeline instance.
+
+The !TimelineEventProvider and ExtensionPoint could be 
+defined as:
+{{{
+#!python
+class ExtensionPoint:
+    def module(self): 
+        """The module providing this client for the timeline"""
+        pass
+    ...
+
+class TimelineEventProvider(ExtensionPoint):
+    def query_string(self):
+        """The SQL fragment which provides:
+ * time: the timestamp of the event
+ * idata: the unique identifier for this event
+ * ... and so on
+"""
+        pass
+
+    def render_item(self,item):
+        """Populate the item dictionary with hdf data"""
+        pass
+    ...
+}}}
+
+--ChristianBoos