[geeklog-devel] RFC: Simplifying PLG_itemSaved

[Website Master]

>A "delete" would certainly make sense. PLG_itemSaved will be called on
>edit, too. Would that be enough? 

Yup it should be as long as if an id changes in an edit we know the old and
the new.

>Not sure if it's a good idea to let plugins mess with other plugin's
>tables. The actual information you're after should be routed through
> PLG_getItemInfo instead, IMO.

Your right, I wasn't thinking clearly. I had forgotten that PLG_getItemInfo
will supply a URL, Title, and summary (that's what I use the table,id column
info for to retrieve the title, desc). I guess PLG_getItemInfo would take
care of any security as well. 

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dirk Haun
Sent: January-17-09 1:42 PM
To: geeklog-devel
Subject: Re: [geeklog-devel] RFC: Simplifying PLG_itemSaved

Website Master wrote:

>How about a PLG_itemDelete, PLG_itemEdit  which will notify plugins and
>Geeklog about delete or edits of stories and other plugins objects.

A "delete" would certainly make sense. PLG_itemSaved will be called on
edit, too. Would that be enough? 



>While we are the topic some mods to PLG_getItemInfo would be helpful in the
>future.

Some extensions will be coming in 1.6.0:

    http://wiki.geeklog.net/wiki/index.php/PLG_getItemInfo


>some plugins also need information about what table the plugin object(s) is
>stored in, the name of the id field(s) and security information.

Not sure if it's a good idea to let plugins mess with other plugin's
tables. The actual information you're after should be routed through
PLG_getItemInfo instead, IMO.


>Also some
>plugins have multiple object types, the current API does not handle this.
As
>example the forum has topics and messages.

Okay, so the $type is actually the name of the plugin. I don't see why
the forum plugin couldn't provide information about topics through
PLG_getItemInfo, though.


>Also it would be a good idea to get the Universal Plugin Toolkit up to
speed
>once everything has been figured out so people know about these APIs (along
>with the core plugins).

I guess providing a plugin skeleton would help. That should not be based
on the plugin API, though, but be rewritten from the ground up to use
autoinstall.php and all the nice new APIs.

The most important help, however, would be updated documentation. Any
volunteers?

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3773 (20090117) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com