Cross Site Publishing and Receiving Information - Revision history

TimPatrick: /* Introduction */

2010-08-16T21:49:38Z

‎Introduction

TimPatrick: /* Plugins and using the API */

2010-08-16T21:49:07Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T21:44:35Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:30:28Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:30:12Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:22:20Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:18:09Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:12:11Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:11:51Z

‎Plugins and using the API

TimPatrick: /* Plugins and using the API */

2010-08-16T19:10:10Z

‎Plugins and using the API

← Older revision		Revision as of 21:49, 16 August 2010
Line 6:		Line 6:

	Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).		Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).
		+
		+	'''NOTE: This guide is IN PROGESS so until this message is removed then the information is NOT COMPLETE'''

	= Overview, Groups, Feeds, Data =		= Overview, Groups, Feeds, Data =

← Older revision		Revision as of 21:49, 16 August 2010
Line 85:		Line 85:
	The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.		The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.
	The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.		The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.
		+	You can register a new access code at the main geeklog site for use with your plugin. You are also able to use an existing access code for your plugin if you want to use data intending for another use.

← Older revision		Revision as of 21:44, 16 August 2010
Line 81:		Line 81:

	</pre>		</pre>
		+
		+
		+	The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.
		+	The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.

@@ Line 41: / Line 41: @@
 * Managing security and subscriptions - PublishingSecurityManagement
 * Managing types - TypeObject
 For receiving, there is only one class
 * ReceivingControlManagement
 Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.

@@ Line 42: / Line 42: @@
 * Managing types - TypeObject
+For receiving, there is only one class
 Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.

@@ Line 31: / Line 31: @@
 All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.
 Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
@@ Line 65: / Line 77: @@
 </pre>

@@ Line 29: / Line 29: @@
 Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.
 Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
@@ Line 45: / Line 47: @@
 method that matches the unique title against the database to retrieve the ID for the group.
 A case study that will help understand how to create a plugin that uses these features is the cross site alert plugin, that allows sites to create alerts and share them.

@@ Line 42: / Line 42: @@
 You can then always get the group id for this group by using the
 <pre>
-PublishingGroupControl::getIdForNDTitle</pre>
+PublishingGroupControl::getIdForNDTitle($title)</pre>
 method that matches the unique title against the database to retrieve the ID for the group.

@@ Line 35: / Line 35: @@
 If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
-The format for a unique group name is: `Plugin Full Name - plugin_dir_name - % - randomvalue` eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
+The format for a unique group name is:
-You can then always get the group id for this group by using the `PublishingGroupControl::getIdForNDTitle` method that matches the unique title against the database to retrieve the ID for the group.
+<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`

← Older revision		Revision as of 19:10, 16 August 2010
Line 27:		Line 27:

	NOTE: @Result, directions for including lib files if not integrated into geeklog		NOTE: @Result, directions for including lib files if not integrated into geeklog
		+
		+	Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.
		+
		+	Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
		+	Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
		+	This feature is called `no display`.
		+
		+	If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
		+	The format for a unique group name is: `Plugin Full Name - plugin_dir_name - % - randomvalue` eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
		+	You can then always get the group id for this group by using the `PublishingGroupControl::getIdForNDTitle` method that matches the unique title against the database to retrieve the ID for the group.