Welcome to Geeklog, Anonymous Thursday, March 28 2024 @ 06:04 pm EDT

Geeklog Forums

Plugin development questions


ldomenech

Anonymous
Hi there, Still working on a plugin, I have a few questions: - Is there any parameter to the plugin_itemlist_ function? - How do I get the search type to show up in the Search list? (plugin_getsearchtypes_ doesn't seem to be enough. - How do I get to have mu entries to show up in the user and admin blocks? (Again plugin_showuseroptions_ and plugin_adminoptions_ don't seem to be working alone...) Thanks in advance, Laurent
 Quote

Status: offline

Tony

Site Admin
Admin
Registered: 12/17/01
Posts: 405
Location:Urbandale, Iowa
Did you insert a record into the plugin table? All the plugin code first checks all plugins in the plugin table that have enabled set to 1. I bet if you insert that record it will fix all your troubles. Also, email me with suggestions on how the plugin API could be better. Your the first person besides me to try developing any. If you haven't already, you may want to reverse engineer the staticpages plugins as it handles most of the plug-in API minus the submission stuff. ----- The reason people blame things on previous generations is that there's only one other choice.
The reason people blame things on previous generations is that there's only one other choice.
 Quote

ldomenech

Anonymous
Yes, there is a record in the plugin table. Although I installed it manually it is listed in the Plugins admin page. Do you see something else?
 Quote

gnuyen

Anonymous
No arguments are passed to plugin_itemlist_<pluginname> AFAIK. The bizzare thing about it is it seems the only part of the API to use classes (I think it is the beginning of a trend). An example: function plugin_itemlist_dog() { $returnPlugin = new Plugin(); $returnPlugin->submissionlabel = 'Dog Submissions'; $returnPlugin->getsubmissionssql = 'SELECT did, name, breed FROM dogsubmission'; $returnPlugin->submissionheading = array('name,breed'); return $returnPlugin; } I don't know if this is the 'correct' way, but it works. Also, note that getsubmissionsql seems to be a field and not a method oddly enough, and that you leave out the ID from submissionheading (or else stuff gets messed up). Hope that helps! --- Gnuyen
 Quote

gnuyen

Anonymous
If you'd like some suggestions on how to improve the plugin interface here are a few: Either make return values all classes or no classes, returning arrays some of the time and Plugins other parts of the time is at best odd. Also, I think plugins should be split into type handlers and modules, for there's no need to force that all type handlers have their own directory off the site_url. This prevents modules from utilizing multiple types (many modules [like mine] require multiple types e.g. phpbb has posts vs private messages etc which might have different databases for comments as well as different submission forms). Make a Module Class of which all plugins will be derivations . Also make a Type Class for types. This way we can get around all that forced naming stuff. I.e $th = new COM_getTypeHandler('<type>', maybesomeargs); $th->getItemList(); $th->Submit(); etc... where COM_getTypeHandler calls the registered constructor for that Type. Also, For purposes of orthogonality (and to provide good examples on how plugins work) convert links and events to plugins. Another thing, I don't see anywhere in the code where it's required that the plugin's submission table really needs to be named <pluginname>submission and the regular table needs to be <pluginname>. If this was a requirement I'd suggest removing it, but AFAICS it's not actually really a requirement since you specify the table in plugin_moderationvalues_<pluginname> as well as passing SQL around everywhere else.
 Quote

gnuyen

Anonymous
I don't really get the security module for different plugins, I can't really tell but it seems that plugin admins get to handle all the plugin type submissions? I don't think thats actually how it is, but if it is that should be changed so each type or module can have it's own admin groups.
 Quote

Status: offline

epretorious

Forum User
Junior
Registered: 07/02/02
Posts: 26
I've managed to sucessfully reverse-engineer almost every other plugin API but this one is too absurd!
  1. The object-oriented nature of this API makes it difficult enough to understand but...
  2. The criss-crossing of function calls is what makes this especially problematic for plugin designers. i.e., moderation.php::commandcontrol() calls lib-plugins.php:RazzLG_showModerationList(). lib-plugins.php:RazzLG_showModerationList() - in turn - calls moderation.php::itemlist() repeatedly instead of havingt PLG_showModerationList() return a list to moderation.php::commandcontrol() and letting commandcontrol() iterate over the list along with the default values of 'story', 'link', and 'event'.
Stop the merry-go-round - I'm getting dizzy!!!

---
Eric P.
Sunnyvale, CA


Eric P.
Sunnyvale, CA
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany

Your point being ...?

FYI, Tom Willet and Blaine Lang are currently working on a better documentation of the plugin interface, see this story on Tom's site.

If you have any proper suggestions on how to improve the plugin interface then I'd suggest you voice them on the geeklog-devel mailing list. While it is unlikely that we will introduce any incompatible changes in the 1.3.x plugin API, your input may be of interest for the design of the GL2 API.

bye, Dirk

 Quote

Status: offline

epretorious

Forum User
Junior
Registered: 07/02/02
Posts: 26
Sorry... I just had to rant. :^(---Eric P. Sunnyvale, CA
Eric P.
Sunnyvale, CA
 Quote

All times are EDT. The time is now 06:04 pm.

  • Normal Topic
  • Sticky Topic
  • Locked Topic
  • New Post
  • Sticky Topic W/ New Post
  • Locked Topic W/ New Post
  •  View Anonymous Posts
  •  Able to post
  •  Filtered HTML Allowed
  •  Censored Content