Extending ccPublisher - Revision history

Ewoudenberg: /* Registration */

2007-01-05T14:59:54Z

‎Registration

Nathan Yergler at 14:43, 1 June 2006

2006-06-01T14:43:36Z

Nathan Yergler at 16:26, 16 May 2006

2006-05-16T16:26:12Z

Nathan Yergler at 00:51, 16 May 2006

2006-05-16T00:51:52Z

Nathan Yergler at 00:29, 16 May 2006

2006-05-16T00:29:25Z

Nathan Yergler at 00:25, 16 May 2006

2006-05-16T00:25:46Z

Nathan Yergler at 00:10, 16 May 2006

2006-05-16T00:10:21Z

Nathan Yergler at 21:02, 15 May 2006

2006-05-15T21:02:46Z

Nathan Yergler at 20:44, 15 May 2006

2006-05-15T20:44:53Z

Nathan Yergler: Initial content outline...

2006-05-15T19:21:29Z

Initial content outline...

New page

ccPublisher 2 has been designed for extensibility and customization by 3rd party developers. This document covers extending ccPublisher 2 and other P6-based applications through the use of extensions.

== Overview ==

== Creating An Extension ==

=== Responding to Events ===

=== Contributing to the User Interface ===

== Extension Patterns ==

=== Post-Upload activities ===

=== Storage Providers ===

@@ Line 45: / Line 45: @@
 The <code>extension</code> directive registers the extension with the P6 framework and intializes the translation mechanism.  See [[Translating Extensions]] for more information on translating your extension.
-Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission (the Stored event).  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.  Subscribers should always be for an interface and not a specific class that implements the interface.  This allows the application to be extended in a way that will be consisten to the user.
+Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission (the Stored event).  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.  Subscribers should always be for an interface and not a specific class that implements the interface.  This allows the application to be extended in a way that will be consistent to the user.
 Note that Python must be able to import the package path for the subscriber handler(the value, less the final element); in this case, Python will attempt to import the <code>blogping.handlers</code> module.  This implies that the code must be on the application's Python path.  P6 places all subdirectories of the <code>extensions</code> directory into the Python before loading extensions.  See [[Distributing Extensions]] for details on platform-specific extension locations.

@@ Line 31: / Line 31: @@
       id="org.cc.p6.sample.blog_ping"
       name="Blog Ping Example"
-      config_factory="blogping.config"
+      description="A sample extension which pings the user's blog"
+   />
      <subscriber
@@ Line 38: / Line 38: @@
            handler="blogping.handlers.afterStored"
            />
-   </extension>
   </configure>
 In this example we first declare a <code><configure></code> object, which all of our configuration will take place within.  The i18n_domain attribute will be used for transparent internationalization.
-The remainder of the configuration takes place within an <code><extension></code> element.  The extension element defines an id and name (both required), and an optional config_factory.  The value of config_factory is a Python callable which will display the extensions configuration UI when called.  Note that Python must be able to import the package path (the value, less the final element); in this case, Python will attempt to import the <code>blogping</code> module.  Note that this implies that the code must be on the application's Python path.  P6 places all subdirectories of the <code>extensions</code> directory into the Python before loading extensions.  See [[Distributing Extensions]] for details on platform-specific extension locations.
+The <code>extension</code> directive registers the extension with the P6 framework and intializes the translation mechanism.  See [[Translating Extensions]] for more information on translating your extension.
 Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission (the Stored event).  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.  Subscribers should always be for an interface and not a specific class that implements the interface.  This allows the application to be extended in a way that will be consisten to the user.
 === Responding to Events ===

@@ Line 1: / Line 1: @@
 [[Category:CcPublisher]]
 [[Category:Developer]]
 ccPublisher 2 has been designed for extensibility and customization by 3rd party developers. This document covers extending ccPublisher 2 and other P6-based applications through the use of extensions.

@@ Line 44: / Line 44: @@
 In this example we first declare a <code><configure></code> object, which all of our configuration will take place within.  The i18n_domain attribute will be used for transparent internationalization.
-The remainder of the configuration takes place within an <code><extension></code> element.  The extension element defines an id and name (both required), and an optional config_factory.  The value of config_factory is a Python callable which will display the extensions configuration UI when called.  Note that Python must be able to import the package path (the value, less the final element); in this case, Python will attempt to import the <code>blogping</code> module.  Note that this implies that the code must be on the application's Python path.  P6 places all subdirectories of the <code>extensions</code> directory into the Python before loading extensions.  See [[Installing Extensions]] for details on platform-specific extension locations.
+The remainder of the configuration takes place within an <code><extension></code> element.  The extension element defines an id and name (both required), and an optional config_factory.  The value of config_factory is a Python callable which will display the extensions configuration UI when called.  Note that Python must be able to import the package path (the value, less the final element); in this case, Python will attempt to import the <code>blogping</code> module.  Note that this implies that the code must be on the application's Python path.  P6 places all subdirectories of the <code>extensions</code> directory into the Python before loading extensions.  See [[Distributing Extensions]] for details on platform-specific extension locations.
 Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission (the Stored event).  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.  Subscribers should always be for an interface and not a specific class that implements the interface.  This allows the application to be extended in a way that will be consisten to the user.

@@ Line 63: / Line 63: @@
 Applications can allow extensions to contribute to the user interface through the use of [[Extension Point|Extension Points]].  An extension point declares a place in the application where extensions have the opportunity to insert one or more pages to collect specific information.  For example, the blog ping extension may need to ask the user for the URL to use for the XML-RPC interface for their blog.  To accomplish this for ccPublisher the blog ping extension would want to implement the <code>IStorageMetaCollection</code> extension point.
-Extension Points are declared by the application in <code>[[app.zcml]]</code> as a wizard page.  An application may conceivably declare extension points which are not implemented by the default feature set, as a service to future extensions.  Each extension point is declared to be ''for'' a particular interface.  A sample declaration, taken from ccPublisher's app.zcml, declares an extension point that is intended to allow storage providers to collect provider-specific metadata before the upload occurs.
+Extension Points are declared by the application in <code>[[App_zcml|app.zcml]]</code> as a wizard page.  An application may conceivably declare extension points which are not implemented by the default feature set, as a service to future extensions.  Each extension point is declared to be ''for'' a particular interface.  A sample declaration, taken from ccPublisher's app.zcml, declares an extension point that is intended to allow storage providers to collect provider-specific metadata before the upload occurs.
      <extensionPoint

@@ Line 66: / Line 66: @@
      <extensionPoint
-	for="p6.extension.interfaces.IStorageMetaCollection" />
+       for="p6.extension.interfaces.IStorageMetaCollection" />
 As with extensions, the interface an extension point is declared for must be importable from Python.
@@ Line 142: / Line 142: @@
 === Post-Upload activities ===
 === Storage Providers ===
 == Future Directions ==
 The Extension API is relatively new and so still under development.  See [[P6 Extension Ideas]] for possible extension ideas and API suggestions.'

@@ Line 4: / Line 4: @@
 ccPublisher 2 has been designed for extensibility and customization by 3rd party developers. This document covers extending ccPublisher 2 and other P6-based applications through the use of extensions.
 == Overview ==
@@ Line 64: / Line 62: @@
 Applications can allow extensions to contribute to the user interface through the use of [[Extension Point|Extension Points]].  An extension point declares a place in the application where extensions have the opportunity to insert one or more pages to collect specific information.  For example, the blog ping extension may need to ask the user for the URL to use for the XML-RPC interface for their blog.  To accomplish this for ccPublisher the blog ping extension would want to implement the <code>IStorageMetaCollection</code> extension point.
 == Extension Patterns ==

@@ Line 26: / Line 26: @@
              xmlns:i18n="http://namespaces.zope.org/i18n"
              i18n_domain="org_cc_p6">
-−
    &lt;!-- P6 Sample Extension Configuration
         (c) 2005-2006, Nathan R. Yergler, Creative Commons
         licensed under the GNU GPL 2                   -->
-−
    <extension
       id="org.cc.p6.sample.blog_ping"
@@ Line 36: / Line 36: @@
       config_factory="blogping.config"
+   >
      <subscriber
            for="p6.storage.events.IStored"
@@ Line 47: / Line 48: @@
 The remainder of the configuration takes place within an <code><extension></code> element.  The extension element defines an id and name (both required), and an optional config_factory.  The value of config_factory is a Python callable which will display the extensions configuration UI when called.  Note that Python must be able to import the package path (the value, less the final element); in this case, Python will attempt to import the <code>blogping</code> module.  Note that this implies that the code must be on the application's Python path.  P6 places all subdirectories of the <code>extensions</code> directory into the Python before loading extensions.  See [[Installing Extensions]] for details on platform-specific extension locations.
-Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission.  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.
+Finally, we define a <code><subscriber></code> which registers a callable (blogping.handlers.afterStored) which will be called after all storage providers have processed the submission (the Stored event).  This callable should be a standard Zope3 event-handler; that is, it will be passed a single parameter.  That parameter will be an event object which implements <code>p6.storage.events.IStored</code>.  Subscribers should always be for an interface and not a specific class that implements the interface.  This allows the application to be extended in a way that will be consisten to the user.
 === Responding to Events ===
 === Contributing to the User Interface ===
 == Extension Patterns ==