[geeklog-devtalk] geeklog-devel digest, Vol 1 #209 - 4 msgs

[geeklog-devtalk-admin at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Re: Geeklog 2 Module API (Blaine Lang)
   2. Re: Re: Geeklog 2 Module API (Tony Bibbs)
   3. Re: Re: Geeklog 2 Module API (Tony Bibbs)
   4. Re: Re: Geeklog 2 Module API (Tony Bibbs)

--__--__--

Message: 1
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Date: Mon, 20 Oct 2003 14:55:40 -0400
Reply-To: geeklog-devel at lists.geeklog.net

Vinny,

I like the idea of having the plugin register itself with their capabilties.
As Tom notes, there may also be a way for a plugin to advertise new services
that may be available.

- Examples that I have close to release are:
1) Support for Smilies - Add/Edit Admin plus the replace functions but
standard Story Edit and Comment functions could also use this
2) Private Messenger - The one in chatterblock was a quick hack compared to
the new one I have now but other plugins may want to leverage this feature.
Example, I created a Project Mgmt Plugin for a client and they wanted the
options to received task notifications via the Private Messenger.

Another example is an image mgmt plugin that would provide a service to
allow users to add images to stories or other plugins that have content
functionality.

But as Tom notes, we will need someway to facilite or mediate over
conflicts.

Would there be a need to have or want a plugin function replace a core
function ?

I was not sure if you have used the most recent release when you reviewed
the PLG API functions. Dirk has added a number of new ones for syndication.

What about an internal Messaging protocal or service for plugins and Core
compoents to share or exchange information ?

GL 1.3.8 Added the new functions to extend the User and Account Profiles -
this was a great addition. If only now we had a way to auto extend or modify
the templates. GL2 will need to support a much improved template engine as
noted many times < but I digress off topic>
Is there a need to add an API to add/edit information to the cookie or
session variables ?

I can't think of any new API's that are needed. The 1.3.x framework has been
very good at fleshing this out and it's been nicely extended over the past
year.  I have not looked at XOOPS2 to see what they have done -  that may be
helpfull for ideas.

I'd like to see a way to import in a new plugin. Similar to a JAR file - a
zip file with the defined structure. The Plugin installer would un-archive
the contents, create the directories and run the installer script. I'd put
my hand up to work on that one. I think we need to also look at the Block
admin and have a similar feature.

Note: We may want to move some of the GL2 Discussion to the Geeklog.net
Forum. I can create a Developers Category and Forums that are restricted.

----- Original Message -----
From: "Vincent Furia" <vmf at abtech.org>
To: "Tony Bibbs" <tony at tonybibbs.com>
Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
Sent: Monday, October 20, 2003 2:29 AM
Subject: [geeklog-devel] Re: Geeklog 2 Module API



> OK, here is a first go at the module/plugin API to get things started.

> I thought that I would start by recommending that plugins "register"

> themselves during install with geeklog, including whether they use the

> different plugin APIs (moderation, comments, ratings, search, etc) so as

> to eliminate the "doesXXXX" type functions that may be needed otherwise

> (should also make things more efficient when calling functions for

> multiple plugins).

>

> In any case, please make lots of recommendations.  This doesn't really

> add much to what a plugin can do in GL 1.3.x, any new ideas would be

> very much appreciated.

>

> -Vinny

>

> <?php

> interface glPlugin {

>     /* installation functions */

>     function install();                /* install the plugin */

>     function uninstall();            /* uninstall the plugin */

>     function upgrade();                /* upgrade the plugin from a

> previous version */

>     function getVersion();            /* return plugin name and version

> (author(s)?, website?)*/

>

>     /* user modifications */

>     function onNewUser();            /* process new user */

>     function onDeleteUser();        /* process user deletion */

>

>     /* moderation */

>     function getSubmissionForm();    /* return the form for plugin

> submission */

>     function getModerationList();    /* return list of items for

> moderation */

>     function onApproveSubmission();    /* process a submission approval */

>     function onDeleteSubmission();    /* delete a submission */

>     function onEditSubmission();    /* return the form to edit a

> submission */

>     function getSubmissionCount();  /* return count of current

> submissions */

>

>     /* search functions */

>     function getSearchResults();    /* search items for keywords */

>     function getSearchTypes();        /* return plugin search options */

>

>     /* comment functions */

>     function onCommentAction();        /* plugin action on comment

> submit, delete, etc */

>     function getCommentParent();    /* for display of the parent above

> comments */

>

>     /* ratings functions */

>     function onRatingAction();        /* plugin action  on ratings

> actions (submit rating) */

>

>     /* menu/display items */

>     function getMenuItems();        /* return menu items related to the

> plugin */

>     function getUserMenu();            /* return user menu options */

>     function getAdminMenu();        /* return admin menu options */

>     function getControlMenu();        /* return control menu options */

>     function getCenterBlock();        /* return centerblock */

>

>     /* profile */

>     function getProfileBlock();        /* display plugin block profile

> values */

>     function getEditProfileBlock();    /* return form to edit block

> profile values */

>     function getProfileVar();        /* display plugin variable profile

> values */

>     function getEditProfileVar();    /* return form to edit variable

> profile values */

>     function saveProfileOptions();  /* save plugin profile options */

>

>     /* export files (rdf feeds, ical files, etc) */

>     function getExportNames();        /* return export file names the

> plugin uses */

>     function getExportContent();    /* return export file content */

>     function getExportCurrent();    /* return if exports are current */

>

>     /* other */

>     function getHeaderCode();        /* return plugin JS or Meta Data */

>     function getStats();            /* return plugin stats information */

> }

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel



--__--__--

Message: 2
Date: Mon, 20 Oct 2003 16:46:31 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net

Please note that GL2 has messenging capabilities built into the core 
parts of the code (as shown by the data model).  I couldn't agree more, 
modules may want to make use of this for sure.

As for modules interacting with one another, I think we need to 
implement observer/observable patterns.  In this scenario, a module can 
register events with Geeklog (e.g. on submission, on delete, on update, 
etc).  For each event, another module can register as an observer to the 
event of another.

This isn't anything but I"m suggesting methods like this:

// this, would be called during an installation of a module
function registerEvents($eventArray);

// this is called by the module when an event occurs
function raiseEvent($eventName);

// This is implemented by the listener of some othe module
function handleEvent($moduleName, $eventName);

This make sense?

--Tony

Blaine Lang wrote:

> Vinny,

> 

> I like the idea of having the plugin register itself with their capabilties.

> As Tom notes, there may also be a way for a plugin to advertise new services

> that may be available.

> 

> - Examples that I have close to release are:

> 1) Support for Smilies - Add/Edit Admin plus the replace functions but

> standard Story Edit and Comment functions could also use this

> 2) Private Messenger - The one in chatterblock was a quick hack compared to

> the new one I have now but other plugins may want to leverage this feature.

> Example, I created a Project Mgmt Plugin for a client and they wanted the

> options to received task notifications via the Private Messenger.

> 

> Another example is an image mgmt plugin that would provide a service to

> allow users to add images to stories or other plugins that have content

> functionality.

> 

> But as Tom notes, we will need someway to facilite or mediate over

> conflicts.

> 

> Would there be a need to have or want a plugin function replace a core

> function ?

> 

> I was not sure if you have used the most recent release when you reviewed

> the PLG API functions. Dirk has added a number of new ones for syndication.

> 

> What about an internal Messaging protocal or service for plugins and Core

> compoents to share or exchange information ?

> 

> GL 1.3.8 Added the new functions to extend the User and Account Profiles -

> this was a great addition. If only now we had a way to auto extend or modify

> the templates. GL2 will need to support a much improved template engine as

> noted many times < but I digress off topic>

> Is there a need to add an API to add/edit information to the cookie or

> session variables ?

> 

> I can't think of any new API's that are needed. The 1.3.x framework has been

> very good at fleshing this out and it's been nicely extended over the past

> year.  I have not looked at XOOPS2 to see what they have done -  that may be

> helpfull for ideas.

> 

> I'd like to see a way to import in a new plugin. Similar to a JAR file - a

> zip file with the defined structure. The Plugin installer would un-archive

> the contents, create the directories and run the installer script. I'd put

> my hand up to work on that one. I think we need to also look at the Block

> admin and have a similar feature.

> 

> Note: We may want to move some of the GL2 Discussion to the Geeklog.net

> Forum. I can create a Developers Category and Forums that are restricted.

> 

> ----- Original Message -----

> From: "Vincent Furia" <vmf at abtech.org>

> To: "Tony Bibbs" <tony at tonybibbs.com>

> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>

> Sent: Monday, October 20, 2003 2:29 AM

> Subject: [geeklog-devel] Re: Geeklog 2 Module API

> 

> 

> 

>>OK, here is a first go at the module/plugin API to get things started.

>>I thought that I would start by recommending that plugins "register"

>>themselves during install with geeklog, including whether they use the

>>different plugin APIs (moderation, comments, ratings, search, etc) so as

>>to eliminate the "doesXXXX" type functions that may be needed otherwise

>>(should also make things more efficient when calling functions for

>>multiple plugins).

>>

>>In any case, please make lots of recommendations.  This doesn't really

>>add much to what a plugin can do in GL 1.3.x, any new ideas would be

>>very much appreciated.

>>

>>-Vinny

>>

>><?php

>>interface glPlugin {

>>    /* installation functions */

>>    function install();                /* install the plugin */

>>    function uninstall();            /* uninstall the plugin */

>>    function upgrade();                /* upgrade the plugin from a

>>previous version */

>>    function getVersion();            /* return plugin name and version

>>(author(s)?, website?)*/

>>

>>    /* user modifications */

>>    function onNewUser();            /* process new user */

>>    function onDeleteUser();        /* process user deletion */

>>

>>    /* moderation */

>>    function getSubmissionForm();    /* return the form for plugin

>>submission */

>>    function getModerationList();    /* return list of items for

>>moderation */

>>    function onApproveSubmission();    /* process a submission approval */

>>    function onDeleteSubmission();    /* delete a submission */

>>    function onEditSubmission();    /* return the form to edit a

>>submission */

>>    function getSubmissionCount();  /* return count of current

>>submissions */

>>

>>    /* search functions */

>>    function getSearchResults();    /* search items for keywords */

>>    function getSearchTypes();        /* return plugin search options */

>>

>>    /* comment functions */

>>    function onCommentAction();        /* plugin action on comment

>>submit, delete, etc */

>>    function getCommentParent();    /* for display of the parent above

>>comments */

>>

>>    /* ratings functions */

>>    function onRatingAction();        /* plugin action  on ratings

>>actions (submit rating) */

>>

>>    /* menu/display items */

>>    function getMenuItems();        /* return menu items related to the

>>plugin */

>>    function getUserMenu();            /* return user menu options */

>>    function getAdminMenu();        /* return admin menu options */

>>    function getControlMenu();        /* return control menu options */

>>    function getCenterBlock();        /* return centerblock */

>>

>>    /* profile */

>>    function getProfileBlock();        /* display plugin block profile

>>values */

>>    function getEditProfileBlock();    /* return form to edit block

>>profile values */

>>    function getProfileVar();        /* display plugin variable profile

>>values */

>>    function getEditProfileVar();    /* return form to edit variable

>>profile values */

>>    function saveProfileOptions();  /* save plugin profile options */

>>

>>    /* export files (rdf feeds, ical files, etc) */

>>    function getExportNames();        /* return export file names the

>>plugin uses */

>>    function getExportContent();    /* return export file content */

>>    function getExportCurrent();    /* return if exports are current */

>>

>>    /* other */

>>    function getHeaderCode();        /* return plugin JS or Meta Data */

>>    function getStats();            /* return plugin stats information */

>>}

>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel


-- 
+----------------------------------------------------------------------+

|Tony Bibbs         |[R]egardless of what you may think of our penal   |

|tony at tonybibbs.com |system, the fact is that every man in jail is one |

|                   |less potential fisherman to clutter up your       |

|                   |favorite pool or pond. --Ed Zern                  |

+----------------------------------------------------------------------+


--__--__--

Message: 3
Date: Mon, 20 Oct 2003 18:25:59 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net

Related to this, I'd like to see modules be more flexible than simply 
supporting center blocks.  I have been reading a bit on the Java Portlet 
technology that basically allows you to break a single page up into 
portlets or little windows.  The size of the portlets are configurable 
and it is up to the module to return the content for the individual 
portlet.  I don't feel we should make our solution near as complicated 
as the Java version (otherwise where is our value-add) but I do think we 
should support more flexible layout types.

I will think about how this might effect the API.

--Tony

Blaine Lang wrote:

> Vinny,

> 

> I like the idea of having the plugin register itself with their capabilties.

> As Tom notes, there may also be a way for a plugin to advertise new services

> that may be available.

> 

> - Examples that I have close to release are:

> 1) Support for Smilies - Add/Edit Admin plus the replace functions but

> standard Story Edit and Comment functions could also use this

> 2) Private Messenger - The one in chatterblock was a quick hack compared to

> the new one I have now but other plugins may want to leverage this feature.

> Example, I created a Project Mgmt Plugin for a client and they wanted the

> options to received task notifications via the Private Messenger.

> 

> Another example is an image mgmt plugin that would provide a service to

> allow users to add images to stories or other plugins that have content

> functionality.

> 

> But as Tom notes, we will need someway to facilite or mediate over

> conflicts.

> 

> Would there be a need to have or want a plugin function replace a core

> function ?

> 

> I was not sure if you have used the most recent release when you reviewed

> the PLG API functions. Dirk has added a number of new ones for syndication.

> 

> What about an internal Messaging protocal or service for plugins and Core

> compoents to share or exchange information ?

> 

> GL 1.3.8 Added the new functions to extend the User and Account Profiles -

> this was a great addition. If only now we had a way to auto extend or modify

> the templates. GL2 will need to support a much improved template engine as

> noted many times < but I digress off topic>

> Is there a need to add an API to add/edit information to the cookie or

> session variables ?

> 

> I can't think of any new API's that are needed. The 1.3.x framework has been

> very good at fleshing this out and it's been nicely extended over the past

> year.  I have not looked at XOOPS2 to see what they have done -  that may be

> helpfull for ideas.

> 

> I'd like to see a way to import in a new plugin. Similar to a JAR file - a

> zip file with the defined structure. The Plugin installer would un-archive

> the contents, create the directories and run the installer script. I'd put

> my hand up to work on that one. I think we need to also look at the Block

> admin and have a similar feature.

> 

> Note: We may want to move some of the GL2 Discussion to the Geeklog.net

> Forum. I can create a Developers Category and Forums that are restricted.

> 

> ----- Original Message -----

> From: "Vincent Furia" <vmf at abtech.org>

> To: "Tony Bibbs" <tony at tonybibbs.com>

> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>

> Sent: Monday, October 20, 2003 2:29 AM

> Subject: [geeklog-devel] Re: Geeklog 2 Module API

> 

> 

> 

>>OK, here is a first go at the module/plugin API to get things started.

>>I thought that I would start by recommending that plugins "register"

>>themselves during install with geeklog, including whether they use the

>>different plugin APIs (moderation, comments, ratings, search, etc) so as

>>to eliminate the "doesXXXX" type functions that may be needed otherwise

>>(should also make things more efficient when calling functions for

>>multiple plugins).

>>

>>In any case, please make lots of recommendations.  This doesn't really

>>add much to what a plugin can do in GL 1.3.x, any new ideas would be

>>very much appreciated.

>>

>>-Vinny

>>

>><?php

>>interface glPlugin {

>>    /* installation functions */

>>    function install();                /* install the plugin */

>>    function uninstall();            /* uninstall the plugin */

>>    function upgrade();                /* upgrade the plugin from a

>>previous version */

>>    function getVersion();            /* return plugin name and version

>>(author(s)?, website?)*/

>>

>>    /* user modifications */

>>    function onNewUser();            /* process new user */

>>    function onDeleteUser();        /* process user deletion */

>>

>>    /* moderation */

>>    function getSubmissionForm();    /* return the form for plugin

>>submission */

>>    function getModerationList();    /* return list of items for

>>moderation */

>>    function onApproveSubmission();    /* process a submission approval */

>>    function onDeleteSubmission();    /* delete a submission */

>>    function onEditSubmission();    /* return the form to edit a

>>submission */

>>    function getSubmissionCount();  /* return count of current

>>submissions */

>>

>>    /* search functions */

>>    function getSearchResults();    /* search items for keywords */

>>    function getSearchTypes();        /* return plugin search options */

>>

>>    /* comment functions */

>>    function onCommentAction();        /* plugin action on comment

>>submit, delete, etc */

>>    function getCommentParent();    /* for display of the parent above

>>comments */

>>

>>    /* ratings functions */

>>    function onRatingAction();        /* plugin action  on ratings

>>actions (submit rating) */

>>

>>    /* menu/display items */

>>    function getMenuItems();        /* return menu items related to the

>>plugin */

>>    function getUserMenu();            /* return user menu options */

>>    function getAdminMenu();        /* return admin menu options */

>>    function getControlMenu();        /* return control menu options */

>>    function getCenterBlock();        /* return centerblock */

>>

>>    /* profile */

>>    function getProfileBlock();        /* display plugin block profile

>>values */

>>    function getEditProfileBlock();    /* return form to edit block

>>profile values */

>>    function getProfileVar();        /* display plugin variable profile

>>values */

>>    function getEditProfileVar();    /* return form to edit variable

>>profile values */

>>    function saveProfileOptions();  /* save plugin profile options */

>>

>>    /* export files (rdf feeds, ical files, etc) */

>>    function getExportNames();        /* return export file names the

>>plugin uses */

>>    function getExportContent();    /* return export file content */

>>    function getExportCurrent();    /* return if exports are current */

>>

>>    /* other */

>>    function getHeaderCode();        /* return plugin JS or Meta Data */

>>    function getStats();            /* return plugin stats information */

>>}

>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel



-- 
+-------------------+--------------------------------------------------+

|Tony Bibbs         |[R]egardless of what you may think of our penal   |

|tony at tonybibbs.com |system, the fact is that every man in jail is one |

|                   |less potential fisherman to clutter up your       |

|                   |favorite pool or pond. --Ed Zern                  | 


+-------------------+--------------------------------------------------+


--__--__--

Message: 4
Date: Mon, 20 Oct 2003 18:26:24 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net

Related to this, I'd like to see modules be more flexible than simply 
supporting center blocks.  I have been reading a bit on the Java Portlet 
technology that basically allows you to break a single page up into 
portlets or little windows.  The size of the portlets are configurable 
and it is up to the module to return the content for the individual 
portlet.  I don't feel we should make our solution near as complicated 
as the Java version (otherwise where is our value-add) but I do think we 
should support more flexible layout types.

I will think about how this might effect the API.

--Tony

Blaine Lang wrote:

> Vinny,

> 

> I like the idea of having the plugin register itself with their capabilties.

> As Tom notes, there may also be a way for a plugin to advertise new services

> that may be available.

> 

> - Examples that I have close to release are:

> 1) Support for Smilies - Add/Edit Admin plus the replace functions but

> standard Story Edit and Comment functions could also use this

> 2) Private Messenger - The one in chatterblock was a quick hack compared to

> the new one I have now but other plugins may want to leverage this feature.

> Example, I created a Project Mgmt Plugin for a client and they wanted the

> options to received task notifications via the Private Messenger.

> 

> Another example is an image mgmt plugin that would provide a service to

> allow users to add images to stories or other plugins that have content

> functionality.

> 

> But as Tom notes, we will need someway to facilite or mediate over

> conflicts.

> 

> Would there be a need to have or want a plugin function replace a core

> function ?

> 

> I was not sure if you have used the most recent release when you reviewed

> the PLG API functions. Dirk has added a number of new ones for syndication.

> 

> What about an internal Messaging protocal or service for plugins and Core

> compoents to share or exchange information ?

> 

> GL 1.3.8 Added the new functions to extend the User and Account Profiles -

> this was a great addition. If only now we had a way to auto extend or modify

> the templates. GL2 will need to support a much improved template engine as

> noted many times < but I digress off topic>

> Is there a need to add an API to add/edit information to the cookie or

> session variables ?

> 

> I can't think of any new API's that are needed. The 1.3.x framework has been

> very good at fleshing this out and it's been nicely extended over the past

> year.  I have not looked at XOOPS2 to see what they have done -  that may be

> helpfull for ideas.

> 

> I'd like to see a way to import in a new plugin. Similar to a JAR file - a

> zip file with the defined structure. The Plugin installer would un-archive

> the contents, create the directories and run the installer script. I'd put

> my hand up to work on that one. I think we need to also look at the Block

> admin and have a similar feature.

> 

> Note: We may want to move some of the GL2 Discussion to the Geeklog.net

> Forum. I can create a Developers Category and Forums that are restricted.

> 

> ----- Original Message -----

> From: "Vincent Furia" <vmf at abtech.org>

> To: "Tony Bibbs" <tony at tonybibbs.com>

> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>

> Sent: Monday, October 20, 2003 2:29 AM

> Subject: [geeklog-devel] Re: Geeklog 2 Module API

> 

> 

> 

>>OK, here is a first go at the module/plugin API to get things started.

>>I thought that I would start by recommending that plugins "register"

>>themselves during install with geeklog, including whether they use the

>>different plugin APIs (moderation, comments, ratings, search, etc) so as

>>to eliminate the "doesXXXX" type functions that may be needed otherwise

>>(should also make things more efficient when calling functions for

>>multiple plugins).

>>

>>In any case, please make lots of recommendations.  This doesn't really

>>add much to what a plugin can do in GL 1.3.x, any new ideas would be

>>very much appreciated.

>>

>>-Vinny

>>

>><?php

>>interface glPlugin {

>>    /* installation functions */

>>    function install();                /* install the plugin */

>>    function uninstall();            /* uninstall the plugin */

>>    function upgrade();                /* upgrade the plugin from a

>>previous version */

>>    function getVersion();            /* return plugin name and version

>>(author(s)?, website?)*/

>>

>>    /* user modifications */

>>    function onNewUser();            /* process new user */

>>    function onDeleteUser();        /* process user deletion */

>>

>>    /* moderation */

>>    function getSubmissionForm();    /* return the form for plugin

>>submission */

>>    function getModerationList();    /* return list of items for

>>moderation */

>>    function onApproveSubmission();    /* process a submission approval */

>>    function onDeleteSubmission();    /* delete a submission */

>>    function onEditSubmission();    /* return the form to edit a

>>submission */

>>    function getSubmissionCount();  /* return count of current

>>submissions */

>>

>>    /* search functions */

>>    function getSearchResults();    /* search items for keywords */

>>    function getSearchTypes();        /* return plugin search options */

>>

>>    /* comment functions */

>>    function onCommentAction();        /* plugin action on comment

>>submit, delete, etc */

>>    function getCommentParent();    /* for display of the parent above

>>comments */

>>

>>    /* ratings functions */

>>    function onRatingAction();        /* plugin action  on ratings

>>actions (submit rating) */

>>

>>    /* menu/display items */

>>    function getMenuItems();        /* return menu items related to the

>>plugin */

>>    function getUserMenu();            /* return user menu options */

>>    function getAdminMenu();        /* return admin menu options */

>>    function getControlMenu();        /* return control menu options */

>>    function getCenterBlock();        /* return centerblock */

>>

>>    /* profile */

>>    function getProfileBlock();        /* display plugin block profile

>>values */

>>    function getEditProfileBlock();    /* return form to edit block

>>profile values */

>>    function getProfileVar();        /* display plugin variable profile

>>values */

>>    function getEditProfileVar();    /* return form to edit variable

>>profile values */

>>    function saveProfileOptions();  /* save plugin profile options */

>>

>>    /* export files (rdf feeds, ical files, etc) */

>>    function getExportNames();        /* return export file names the

>>plugin uses */

>>    function getExportContent();    /* return export file content */

>>    function getExportCurrent();    /* return if exports are current */

>>

>>    /* other */

>>    function getHeaderCode();        /* return plugin JS or Meta Data */

>>    function getStats();            /* return plugin stats information */

>>}

>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel



-- 
+-------------------+--------------------------------------------------+

|Tony Bibbs         |[R]egardless of what you may think of our penal   |

|tony at tonybibbs.com |system, the fact is that every man in jail is one |

|                   |less potential fisherman to clutter up your       |

|                   |favorite pool or pond. --Ed Zern                  | 


+-------------------+--------------------------------------------------+



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest