[geeklog-modules] Geeklog plugin API Enhancements

[Tony Bibbs]

Tom Willett wrote:
> On Fri, 17 Jan 2003 20:53:37 -0600, Tony Bibbs wrote

> 
> So is this for 1.3.x only, right?  GL2 will not distinguish between columns.
> 

Right, I'm talking all 1.3.x for now.  The GL2 requirements for the 
plugin API will be drafted this week.

> 
>2) UserSettings API: Tom brought up a good point here on user...
> 
> Optional unless the plugin had user specific settings?

Right, this would be optional

> 
> So the API would specify that the plugin return an independent block of html 
> that can be placed anywhere on a page.  Do you then need a new template 
> similiar to a block or would you want to use the block template for this?
> Could this same template be used by the plugin to display this information 
> elsewhere?  (Blaine's user control panel).  

Good questions.  I think the block should be configurable sorta like 
blocks.  With blocks you can override the template defaults by 
specifiying it in the function file in the layout.

> 
> Do you need a variable that specifies what tab you are on so that it returns 
> to that tab or do you want to always return to the first tab.  

This should make the user experience as intuitive as possible.

> 
> In the API specify that all the plugins variables used on this tab have a 
> unique prefix to avoid naming collisions.  

Good idea.

> 
> Do you want one big form consisting of all tabs or seperate forms for each 
> tab?

The tabbed interface should be pretty simple.  When on the main user 
settings page you would be on the GL form.  When you click something 
like the static pages tab, this would be caught in a GET variable and 
then GL would call the user settings API function for that plugin.

> 
> 
>3) getRelated().  Maybe this needs to be a function that plugins can...
 >
> Optional?
> 
> So the call to getRelated() would return both GL and Plugin related data.  
> Does the instance where the caller and returner are the same need to be 
> handled differently?  I think it necessary that the related data be cached 
> like it is now, but it would also be nice if there was an easy way to 
> refresh the Related Data at a later date.

This needs more thought.  I like this concept but we'd have to touch a 
lot of code.  I'm wondering if this shouldn't be a GL2 thing only.

>4) COM_emailUserTopics(). yes, other plugins may want to format their...
 >
> Optional.
> 
> Just make it a mandatory part of the usersettings API defaulted to off so 
> that the user could turn it on if wanted.

Makes sense.

> Have you thought about the transition to GL2?  Will you provide a backward 
> compatible API so that existing plugins will work with little or no 
> modification or make the clean break?

I think that making GL 1.3.x functions backward compatible will be 
impossible.  A big part of this will be that I my plan is that all 
plugins will inherit from a base plugin object that will set the API so 
that testing of the API can be done before a plugin is release.  That 
may not make sense now but it will when I get you all the first draft of 
the GL API.

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

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