Changes between Version 1 and Version 2 of TracDev/ComponentArchitecture

Timestamp:

May 16, 2005, 5:05:31 PM (19 years ago)

Author:

Christopher Lenz

Comment:

Use own diagrams, backlink to TracDev

TracDev/ComponentArchitecture

@@ -9 +9 @@
 Components can declare ''"extension points"'' that other components can “plug in” to. This allows one component to enhance the functionality of the component it extends, without the extended component even knowing that the extending component exists. All that is needed is that the original component exposes – and uses – one or more extension points.
 
-http://projects.edgewall.com/trac/attachment/wiki/TracPluggableModules/xtnpt.png?format=raw
+http://projects.edgewall.com/trac/attachment/wiki/TracDev%252FComponentArchitecture/xtnpt.png?format=raw
 
 A component can extend any number of other components and still offer its own extension points. This allows a plugin to itself offer a plugin API (i.e. extension point). This feature is the basis for a plugin-based architecture.
@@ -29 +29 @@
   Every extension point specifies the contract that extenders must conform to via an {{{Interface}}} subclass.
 
-http://projects.edgewall.com/trac/attachment/wiki/TracPluggableModules/comparch.png?format=raw
+http://projects.edgewall.com/trac/attachment/wiki/TracDev%252FComponentArchitecture/comparch.png?format=raw
 
 == Declaring a component ==
@@ -145 +145 @@
 
 This output obviously comes from the {{{TodoPrinter}}}. Note however that the code snippet above doesn't even mention that class. All that is needed to have it participating in the action is to declare the class. ''(That implies that an extending class needs to be imported by a python script to be registered. The aspect of loading components is however separate from the extension mechanism itself.)''
+
+----
+See also: TracDev