[geeklog-devel] Plugin API: Extend Admin's story editor

[Blaine Lang]

Dirk,

Great summary and I like the idea of the PLG_itemSaved function also 
handling the condition of the abort and returning the status to the calling 
script.

And I guess your looking a the askPluginsForTheirInputFields() function as 
also being a generic function that would allow any plugin or GL component be 
extended.

Hum .. if we allow additional fields to be added. This would also need to be 
extended to handle edits and deleting.
 - Does edit story allow you to replace the attachement in this case
 - If I delete the story, I need to delete the attachment

Blaine
----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Saturday, February 26, 2005 3:16 PM
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor


Okay, Blaine and I had a little brainstorming session on the phone :-)

On the issue of pre-save vs. post-save:

The good thing about the post-save is that we would only have to pass the
ID of the story to the plugins and they could then get all the
information they need from there. The bad thing is that if one of the
plugins reported a problem, the story would already be saved and visible
on the site, if even for the fraction of a second (which may just be long
enough to make it show up in someone's browser).

This problem wouldn't exist with the pre-save call, but then we would
have to pass around the data in an array and we would have to take care
not to lose that data.

My gut feeling at the moment is that the post-save approach would be more
robust. To prevent the story from showing up temporarily, we'd need
something like the draft flag that's only reset once all the plugins
involved gave their okay (it would be an additional flag - the draft flag
has a different meaning and I don't want to change that).


On the issue of plugins reporting a problem:

We would need an abort call. So say plugin #1 has updated its data, but
then plugin #2 reports a problem. We'd have to issue an abort call to all
the plugins that have been called so far, then go back into the story
editor, displaying all the information the user entered and an error
message, provided by the plugin that caused the abort.

Hmm, we also need to get all the plugin-specific data that the user
entered from somewhere. We still have it in the $_POST array at that
point, so that should be possible.

So far, this would look like this (in pseudo-code):

    story_editor()
    {
        PLG_askPluginsForTheirInputFields()
        displayForm()
    }

Once the user clicks on "save":

    save_story()
    {
        DB_save(...story...) // with status = DONT_PUBLISH_YET
        error = PLG_tellPluginsStoryHasBeenSaved()
        if(error)
        {
            PLG_abortHandlingOfStory()
        }
        else
        {
            // reset DONT_PUBLISH_YET flag, so story can be viewed
        }
    }

Actually, the abort call could be handled in the PLG_ function that
informs the plugins about the story that has been saved, since it knows
which plugins have already been called:

    PLG_storySaved(sid)
    {
        foreach(_PLUGINS)
        {
            if(function_exists('plugin_storysaved'))
            {
                error = plugin_storysaved(sid)
                if(error)
                {
                    foreach(_PLUGINS_SO_FAR)
                    {
                        plugin_abortsave(sid)
                    }
                    return(error)
                }
            }
        }
        return(success)
    }


And now for the fun bit: Since this is all pretty generic, the plugin API
could be generic, too. And every plugin, when saving something, could do
these plugin calls as well. That way, plugins could act on other plugins
saving something. Effectively, this would enable you to extend existing
plugins with your own plugin.

    PLG_itemSaved ($id, $type)

Where, as usual, $id is the generic ID of the item, and $type is the type
of the item ('article', 'comment', etc.). Geeklog would call that
function for everything - stories / storysubmissions, comments,
trackbacks, links / linksubmissions, events / eventsubmissions / personal
events, users, groups, topics, blocks, polls, and feeds. Maybe even for
plugins and backups.

Plugins would have a method

    plugin_itemsaved_pluginname($id, $type)

and could act on the $type if they're interested in it (say, only for
stories and files from the file management plugin) and ignore everything 
else.

This would also replace the current PLG_commentPreSave function. Vinny?


To list a few use cases:

1) Replacement of smilies or BB code in stories and comments.

2) Using the forum as a replacement for comments: On save, the story's
text is copied into a forum post (to start the thread) and the story
itself is modified to include a link to that thread. Add this as an
option to the gl_commentcodes table and you can even select it on a per-
story basis.

3) Pre-populate comments (as in that patch I mentioned in an earlier
post) to encourage comment posters to use certain predefined sub-threads.
The patch mentions a "corrections" and an "off-topic" default comment,
for example.

4) The attachments plugin I'm working on: The user can upload files with
the story (just like images today). The plugin then adds an [attachments:
] autotag to the story's text. When the story is displayed, the
attachments are listed at the end of the story.

I thought #4 would be an example of a plugin extending a plugin, but it
doesn't quite work out. But I'm sure someone will come up with a nifty
idea to use that.

Blaine, did I forget something?

All: Thoughts?

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/

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