[geeklog-devtalk] geeklog-devel digest, Vol 1 #517 - 7 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Plugin API: Extend Admin's story editor (Dirk Haun)
   2. Re: Plugin API: Extend Admin's story editor (Dirk Haun)
   3. Re: Plugin API: Extend Admin's story editor (Blaine Lang)
   4. Re: Plugin API: Extend Admin's story editor (Dirk Haun)
   5. Re: Plugin API: Extend Admin's story editor (Vincent Furia)
   6. Re: Plugin API: Extend Admin's story editor (Dirk Haun)
   7. Re: slashes (/) in comment titles (Dirk Haun)

--__--__--

Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Date: Sat, 26 Feb 2005 18:59:58 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Blaine,


>Is this the API change that you were referring to in a forum post on 

>geeklog.net?


No. The discussion there was about comments and I was referring to the
changes Vinny made to the comment API.



>I wonder if we could not make a generic API for content and then it may be 

>possible to have it used for any content (stories, comments, or other 

>plugins).


Hmm, yes, that may be worth thinking about.



>Can you give some examples of use


Attachments in stories was one example. I've done that with a similar
extension to submit.php, but the client also wants it for admin/story.php.

So the plugin (an extended version of the file management plugin) would
provide extensions of the editor form to add files to upload and once the
story is saved, I'll have to post-process the uploaded files and also add
a new autotag to the story's text.

For another client, I have to ensure that certain permissions are set for
the story.



>and why 

>it's better to do the call after the record is created and not a  PreSave 

>like we have now for the comments.


One problem I already mentioned is when you have several plugins hooked
into the API and one of them reports a problem while another has already
successfully updated its data (e.g. a separate table). I imagine that
it's slightly easier to recover for that plugin if the data has already
been saved.

The other reason was lazyness ;-) A story has - when created from the
Admin's story editor - a lot of fields. All those would have to be passed
to the plugin. In the current story editor, it would require quite a few
changes to be able to pass the data to the plugin in a consistent form.

But I guess if we come up with a proper and solid API, then it would be
worth making those changes.

To summarize, my main issue is that of aborting the save in case one of
the plugins runs into a problem and has to recover (i.e. revert its own
tables back to a state before the save). Other than that a pre-save would
require more changes in the existing code, there's no real reason to
prefer it over a post-save API call.

Maybe the solution would be some sort of abort API call?

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/


--__--__--

Message: 2
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Date: Sat, 26 Feb 2005 21:16:55 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

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/


--__--__--

Message: 3
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Date: Sat, 26 Feb 2005 17:11:42 -0500
Reply-To: geeklog-devel at lists.geeklog.net

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 


--__--__--

Message: 4
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Date: Sun, 27 Feb 2005 00:07:54 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Blaine,


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


Hadn't really thought about that one, but you've got a point there. We
would have to pass the $type as a parameter so that the plugin knows
which form it's asked to extend.



>Hum .. if we allow additional fields to be added. This would also need to be 

>extended to handle edits and deleting.


Good point. We already have a few API functions where we pass a $mode or
$operation parameter, so we could add one here and give the PLG_itemSaved
function an even more generic name, e.g.

    PLG_handleItem ($id, $type, $operation)

where $operation would be one of 'new', 'edit', or 'delete'.


I'm also beginning to worry if the $type is unique enough, now that we
would use more than just 'article' and 'poll'. Maybe we should prefix the
core types with 'geeklog_' or 'core_' to ensure uniqueness.

bye, Dirk


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


--__--__--

Message: 5
Date: Sat, 26 Feb 2005 18:40:56 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Reply-To: geeklog-devel at lists.geeklog.net


> 

>     PLG_handleItem ($id, $type, $operation)

> 

> where $operation would be one of 'new', 'edit', or 'delete'.

> 

Just a personal preference, but I like having different functions for
different operations.  When you have a single function handle
different operations it usually ends up producing some pretty ugly
code.

Otherwise I like everything you've guys have been discussing.  I
definitely like doing the plugin call after the story save, seems much
more sane to me. :)

Nice work,
-Vinny

--__--__--

Message: 6
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Plugin API: Extend Admin's story editor
Date: Sun, 27 Feb 2005 15:02:28 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Vincent Furia wrote:


>Just a personal preference, but I like having different functions for

>different operations.


Fine with me. I tried to keep it consistent with other functions we
already have, but then again consistency is not exactly one of the strong
points of the Geeklog Plugin API ...

bye, Dirk


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


--__--__--

Message: 7
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] slashes (/) in comment titles
Date: Sun, 27 Feb 2005 18:56:13 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Vinny,


>The problem is that if you want a comment with a slash in it ('/') you

>currently need to double slash it to get it in the database so that it

>shows up correctly.  This is a real PITA.


It sure is. And I don't have a solution either. Sorry, just wanted to let
you know that I'm aware of the problem ...

There are a lot of places where Geeklog does too many addslashes() so
that you'll end up with extra backslashes in the DB. Over time, we've
tweaked it such that this goes unnoticed most of the time, but of course
that is no solution. It's some really, really ugly legacy code and I have
no idea how to clean up that mess.

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


End of geeklog-devel Digest