[geeklog-modules] Geeklog plugin API Enhancements

[Tom Willett]

On Fri, 17 Jan 2003 20:53:37 -0600, Tony Bibbs wrote
> Ok, so there are a few new API methods:
> 
> 1) API to support center blocks.

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

> 2) UserSettings API: Tom brought up a good point here on user 
> attributes.  My opinion for 1.3.x is this, we need to make sure that 
> plugin developers *do not* add attributes to the core user table. If 
> they insist on adding an attribute (which is ok) do so in it's on user 
> table that ties to the core table, obviously, by user id.  This way in 
> the event Dirk does get around to adding more user attributes the 
> upgrade for plugin users will still work.
> 
> Also, I'd like to see the preferences page have a tabbed look. On the 
> first table you will see any Gl-core perference setting.  Then each 
> plugin (through this API) can have it's tab show up with it's 
> specialized perferences.  This requires a near rewrite of 
> usersetting.php but it would make things much cleaner an usable.
> 

Optional unless the plugin had user specific settings?

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

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.  

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

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

> 3) getRelated().  Maybe this needs to be a function that plugins can 
> call to have Geeklog search for related stories and return them back to 
> a plugin for inclusion.  Similarly this should work in the reverse where 
> Geeklog can have plugins report related data on a story.  The algorithm 
> used to do the match would be interesting.
> 

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.

> 4) COM_emailUserTopics(). yes, other plugins may want to format their 
> stuff and send it in an email too.  The only issue here is how can users 
> filter? For stories this is tied into the Display Preferences...how 
> would this work for plugins? Is the answer another API in display 
> preferences to get that stuff on a per plugin basis?
> 

Optional.

Just make it a mandatory part of the usersettings API defaulted to off so 
that the user could turn it on if wanted.

> Tom to address your issue about dependencies on plugin names and 
> directories, I understand.  I think this is entrenched enough in GL 
> 1.3.x to leave it as is and, instead, address this in GL2.  Seem 
reasonable?
> 

Yes, I never imagined that this issue would be addressed in 1.3.x.  It would 
break everything.

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?

> 
> Do we need a API call for plugins that is called when users login and
> logout?
>

Optional.

The more I think about this the more I like it -- it opens up posibilites 
for notification and changing the UI per user.

--
Tom Willett
tomw at pigstye.net