Extending ccPublisher - Revision history

Ewoudenberg: /* Registration */

2007-01-05T14:59:54Z

Registration

← Older revision		Revision as of 14:59, 5 January 2007
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.		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.		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.

Nathan Yergler at 14:43, 1 June 2006

2006-06-01T14:43:36Z

← Older revision		Revision as of 14:43, 1 June 2006
Line 31:		Line 31:
	id="org.cc.p6.sample.blog_ping"		id="org.cc.p6.sample.blog_ping"
	name="Blog Ping Example"		name="Blog Ping Example"
	~~config_factory~~="~~blogping.config~~"		description="A sample extension which pings the user's blog"
	>		/>

	<subscriber		<subscriber
Line 38:		Line 38:
	handler="blogping.handlers.afterStored"		handler="blogping.handlers.afterStored"
	/>		/>
	~~</extension>~~
	</configure>		</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.		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.		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.

			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.

	=== Responding to Events ===		=== Responding to Events ===

Nathan Yergler at 16:26, 16 May 2006

2006-05-16T16:26:12Z

← Older revision		Revision as of 16:26, 16 May 2006
Line 1:		Line 1:
	[[Category:CcPublisher]]		[[Category:CcPublisher]]
	[[Category:Developer]]		[[Category:Developer]]
	~~{{incomplete}}~~

	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.		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.

Nathan Yergler at 00:51, 16 May 2006

2006-05-16T00:51:52Z

← Older revision		Revision as of 00:51, 16 May 2006
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.		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.		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.

Nathan Yergler at 00:29, 16 May 2006

2006-05-16T00:29:25Z

← Older revision		Revision as of 00:29, 16 May 2006
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.		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		<extensionPoint

Nathan Yergler at 00:25, 16 May 2006

2006-05-16T00:25:46Z

← Older revision		Revision as of 00:25, 16 May 2006
Line 66:		Line 66:

	<extensionPoint		<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.		As with extensions, the interface an extension point is declared for must be importable from Python.
Line 142:		Line 142:

	=== Post-Upload activities ===		=== Post-Upload activities ===

			A natural model for an extension is to perform some activity after the file upload is completed. There are two pieces of code for implementing such an extension: registering for the appropriate extension point and actually performing the task. For ccPublisher, the extension point to implement is <code>p6.extension.interfaces.IPostStoreExtension</code>.

			When the blog ping extension is complete, we'll have a more concrete and fleshed out example here.

	=== Storage Providers ===		=== Storage Providers ===

			Storage providers are special case extensions. They are registered using a specific ZCML directive (<code>storage</code>), but utilize the same principles as extensions for interacting with the user interface. An important difference is the use of interface decoration. The storage selector page allows users to select one or more repositories to upload their work to. When a repository is chosen, the storage provider has the <code>p6.extension.interfaces.IActivated</code> added to the list of interfaces it implements. When implementing the storage metadata extension point, providers are responsible for checking for the presence of this interface before returning the page list (in <code>list()</code>). Note that the <code>CommonStorageMixin</code> provides a convenience method, <code>activated()</code> which returns True if the storage provider's interface list has been decorated. See [[Writing a Storage Provider]] for more details on Storage Providers.

	== Future Directions ==		== Future Directions ==

	The Extension API is relatively new and so still under development. See [[P6 Extension Ideas]] for possible extension ideas and API suggestions.'		The Extension API is relatively new and so still under development. See [[P6 Extension Ideas]] for possible extension ideas and API suggestions.'

Nathan Yergler at 00:10, 16 May 2006

2006-05-16T00:10:21Z

@@ 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 ==

Nathan Yergler at 21:02, 15 May 2006

2006-05-15T21:02:46Z

← Older revision		Revision as of 21:02, 15 May 2006
Line 26:		Line 26:
	xmlns:i18n="http://namespaces.zope.org/i18n"		xmlns:i18n="http://namespaces.zope.org/i18n"
	i18n_domain="org_cc_p6">		i18n_domain="org_cc_p6">

	<!-- P6 Sample Extension Configuration		<!-- P6 Sample Extension Configuration
	(c) 2005-2006, Nathan R. Yergler, Creative Commons		(c) 2005-2006, Nathan R. Yergler, Creative Commons
	licensed under the GNU GPL 2 -->		licensed under the GNU GPL 2 -->

	<extension		<extension
	id="org.cc.p6.sample.blog_ping"		id="org.cc.p6.sample.blog_ping"
Line 36:		Line 36:
	config_factory="blogping.config"		config_factory="blogping.config"
	>		>

	<subscriber		<subscriber
	for="p6.storage.events.IStored"		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.		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 ===		=== Responding to Events ===

			In the ZCML slug above an event subscriber was declared for the <code>IStored</code> event. The handler is implemented as a Python callable which takes one object, the event. For example, the <code>blogping.handlers</code> module (specified in the <code>handler</code> attribute) might contain the following to print out the metadata collected during the publishing process:

			def afterStored(event):
			"""Simple event handler."""

			print event.metadata

			We know that event has a <code>metadata</code> attribute by examining the interface declaration in <code>p6/storage/events.py</code>.

	=== Contributing to the User Interface ===		=== Contributing to the User Interface ===

			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 ==		== Extension Patterns ==

Nathan Yergler at 20:44, 15 May 2006

2006-05-15T20:44:53Z

@@ Line 1: / Line 1: @@
 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 ===
@@ Line 10: / Line 54: @@
 == Extension Patterns ==
 === Post-Upload activities ===
 === Storage Providers ===

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 ===