[geeklog-devtalk] geeklog-devel digest, Vol 1 #210 - 4 msgs

[geeklog-devtalk-admin 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: Re: Geeklog 2 Module API (Vincent Furia)
   2. Re: Re: Geeklog 2 Module API (Tony Bibbs)
   3. Re: Re: Geeklog 2 Module API (Blaine Lang)
   4. Re: Re: Geeklog 2 Module API (Tony Bibbs)

--__--__--

Message: 1
Date: Tue, 21 Oct 2003 13:18:37 -0700
From: Vincent Furia <vmf at abtech.org>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net

OK, I've included some of the ideas mentioned so far on the thread, 
including those that Warren mentioned on geeklog-devtalk.  The slightly 
modified module API is included below.  I forgot to mention this in the 
previous email, but I had wanted to say that I was only working on the 
call-back functions.  So functions like registering events and APIs 
weren't included because those should be called by the from within the 
plugin code, rather than by the core geeklog code.  Outlining all the 
functions available to the modules would be huge undertaking, but maybe 
something we should work on at the same time as the interace.

Here are some of the functions that would be called by the modules.  
Perhaps these should all be contained within a non-instantiated class?

function registerAPI();
function unregisterAPI();
function registerEvents();
function rasiseEvent();
function getSmiles();
function sendMessage();
function sendEmail();

On top of these there should probably be classes and functions available 
to handle common tasks like file (and image) uploads.

Tony, I'm not an XHTML/CSS deity, but I think a lot could be 
accomplished by modules generating html div blocks that then could be 
modified by css classes.  That combined with some creative function 
calls could get theme developers enough flexibility...  But again, my 
knowledge of css/xhtml isn't thorough enough to know if that would be 
sufficient.

Also that brings us to one of Warren's points about injecting code into 
template files. Should this be handled by functions or by editing the 
template manually...?  I guess this depends on the template system we're 
going to use (looks like FLEXY currently I believe) and what sort of 
magic we can do.  I'm hesitant to create fifty (or however many) 
functions so that the plugins can place code anywhere.  I think we'll 
wind up adding a new function every time a plugin or theme developer 
decides they need access to a new location to achieve a certain look... 
I think this is something we should sort out soon.

Should we move this discussion on the forums?  It really doesn't matter 
to me. We could also move the discussion onto project.geeklog.net which 
might give us a bit more flexibility than using the geeklog.net forums...

Anyway, I just want to emphasize the difference between callback 
functions and functions that will called by the plugin.  It will make 
things easier if everyone keeps the distinction in mind as we work on 
the two simultaneously.

One last question I suppose.  For GL2 are we calling them "plugins", 
"modules" or will we just continue using the two terms interchangably 
until we confuse everyone?  ;)

-Vinny

<?php
interface glPlugin {
    /* installation functions */
    function install();                /* install the plugin */
    function uninstall();            /* uninstall the plugin */
    function upgrade();                /* upgrade the plugin from a 
previous version */
    function getVersion();            /* return plugin name and version 
(author(s)?, website?)*/

    /* user modifications */
    function onNewUser();            /* process new user */
    function onDeleteUser();        /* process user deletion */
    function onLogin();                /* process user login */
    function onLogout();            /* process user logout */

    /* moderation */
    function getSubmissionForm();    /* return the form for plugin 
submission */
    function getModerationList();    /* return list of items for 
moderation */
    function onApproveSubmission();    /* process a submission approval */
    function onDeleteSubmission();    /* delete a submission */
    function onEditSubmission();    /* return the form to edit a 
submission */
    function getSubmissionCount();  /* return count of current 
submissions */

    /* search functions */
    function getSearchResults();    /* search items for keywords */
    function getSearchTypes();        /* return plugin search options */

    /* comment functions */
    function onCommentAction();        /* plugin action on comment 
submit, delete, etc */
    function getCommentParent();    /* for display of the parent above 
comments */

    /* ratings functions */
    function onRatingAction();        /* plugin action  on ratings 
actions (submit rating) */

    /* menu/display items */
    function getMenuItems();        /* return menu items related to the 
plugin */
    function getUserMenu();            /* return user menu options */
    function getAdminMenu();        /* return admin menu options */
    function getControlMenu();        /* return control menu options */
    function getCenterBlock();        /* return centerblock */

    /* profile */
    function getProfileBlock();        /* display plugin block profile 
values */
    function getEditProfileBlock();    /* return form to edit block 
profile values */
    function getProfileVar();        /* display plugin variable profile 
values */
    function getEditProfileVar();    /* return form to edit variable 
profile values */
    function saveProfileOptions();  /* save plugin profile options */

    /* export files (rdf feeds, ical files, etc) */
    function getExportNames();        /* return export file names the 
plugin uses */
    function getExportContent();    /* return export file content */
    function getExportCurrent();    /* return if exports are current */

    /* other */
    function getHeaderCode();        /* return plugin JS or Meta Data */
    function getStats();            /* return plugin stats information */
    function onEvent();                /* handle a registered event */
}


--__--__--

Message: 2
Date: Tue, 21 Oct 2003 17:10:08 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net

The layout portion of this is not going to be the easiest I can already 
see that.  We need to get Knuckles in on this conversation (is the guy 
alive?).  As for my ideas around layout here is what I am thinking. 
First, I think we should consider a method like:

function getBlock($blockName, $width, $height)
{
}

This would allow you to, in a page call for individual blocks directly. 
  Passing the width/height allows some flexibility on the provider of 
the block's content (probably a module) to pick and choose how to 
display itself based on the dimisions (if it wanted to).

Other input on how to add flexibility to the layout yet keep this 
relatively simple would be appreciated.

On another note, should PM's or emails be part of the API or done by 
calling the native GL core code?  Not sure if I have an opinion yet.

Thanks Vinny, it's coming along nicely.

--Tony

Vincent Furia wrote:

> OK, I've included some of the ideas mentioned so far on the thread, 

> including those that Warren mentioned on geeklog-devtalk.  The slightly 

> modified module API is included below.  I forgot to mention this in the 

> previous email, but I had wanted to say that I was only working on the 

> call-back functions.  So functions like registering events and APIs 

> weren't included because those should be called by the from within the 

> plugin code, rather than by the core geeklog code.  Outlining all the 

> functions available to the modules would be huge undertaking, but maybe 

> something we should work on at the same time as the interace.

> 

> Here are some of the functions that would be called by the modules.  

> Perhaps these should all be contained within a non-instantiated class?

> 

> function registerAPI();

> function unregisterAPI();

> function registerEvents();

> function rasiseEvent();

> function getSmiles();

> function sendMessage();

> function sendEmail();

> 

> On top of these there should probably be classes and functions available 

> to handle common tasks like file (and image) uploads.

> 

> Tony, I'm not an XHTML/CSS deity, but I think a lot could be 

> accomplished by modules generating html div blocks that then could be 

> modified by css classes.  That combined with some creative function 

> calls could get theme developers enough flexibility...  But again, my 

> knowledge of css/xhtml isn't thorough enough to know if that would be 

> sufficient.

> 

> Also that brings us to one of Warren's points about injecting code into 

> template files. Should this be handled by functions or by editing the 

> template manually...?  I guess this depends on the template system we're 

> going to use (looks like FLEXY currently I believe) and what sort of 

> magic we can do.  I'm hesitant to create fifty (or however many) 

> functions so that the plugins can place code anywhere.  I think we'll 

> wind up adding a new function every time a plugin or theme developer 

> decides they need access to a new location to achieve a certain look... 

> I think this is something we should sort out soon.

> 

> Should we move this discussion on the forums?  It really doesn't matter 

> to me. We could also move the discussion onto project.geeklog.net which 

> might give us a bit more flexibility than using the geeklog.net forums...

> 

> Anyway, I just want to emphasize the difference between callback 

> functions and functions that will called by the plugin.  It will make 

> things easier if everyone keeps the distinction in mind as we work on 

> the two simultaneously.

> 

> One last question I suppose.  For GL2 are we calling them "plugins", 

> "modules" or will we just continue using the two terms interchangably 

> until we confuse everyone?  ;)

> 

> -Vinny

> 

> <?php

> interface glPlugin {

>    /* installation functions */

>    function install();                /* install the plugin */

>    function uninstall();            /* uninstall the plugin */

>    function upgrade();                /* upgrade the plugin from a 

> previous version */

>    function getVersion();            /* return plugin name and version 

> (author(s)?, website?)*/

> 

>    /* user modifications */

>    function onNewUser();            /* process new user */

>    function onDeleteUser();        /* process user deletion */

>    function onLogin();                /* process user login */

>    function onLogout();            /* process user logout */

> 

>    /* moderation */

>    function getSubmissionForm();    /* return the form for plugin 

> submission */

>    function getModerationList();    /* return list of items for 

> moderation */

>    function onApproveSubmission();    /* process a submission approval */

>    function onDeleteSubmission();    /* delete a submission */

>    function onEditSubmission();    /* return the form to edit a 

> submission */

>    function getSubmissionCount();  /* return count of current 

> submissions */

> 

>    /* search functions */

>    function getSearchResults();    /* search items for keywords */

>    function getSearchTypes();        /* return plugin search options */

> 

>    /* comment functions */

>    function onCommentAction();        /* plugin action on comment 

> submit, delete, etc */

>    function getCommentParent();    /* for display of the parent above 

> comments */

> 

>    /* ratings functions */

>    function onRatingAction();        /* plugin action  on ratings 

> actions (submit rating) */

> 

>    /* menu/display items */

>    function getMenuItems();        /* return menu items related to the 

> plugin */

>    function getUserMenu();            /* return user menu options */

>    function getAdminMenu();        /* return admin menu options */

>    function getControlMenu();        /* return control menu options */

>    function getCenterBlock();        /* return centerblock */

> 

>    /* profile */

>    function getProfileBlock();        /* display plugin block profile 

> values */

>    function getEditProfileBlock();    /* return form to edit block 

> profile values */

>    function getProfileVar();        /* display plugin variable profile 

> values */

>    function getEditProfileVar();    /* return form to edit variable 

> profile values */

>    function saveProfileOptions();  /* save plugin profile options */

> 

>    /* export files (rdf feeds, ical files, etc) */

>    function getExportNames();        /* return export file names the 

> plugin uses */

>    function getExportContent();    /* return export file content */

>    function getExportCurrent();    /* return if exports are current */

> 

>    /* other */

>    function getHeaderCode();        /* return plugin JS or Meta Data */

>    function getStats();            /* return plugin stats information */

>    function onEvent();                /* handle a registered event */

> }

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel


-- 
+----------------------------------------------------------------------+

|Tony Bibbs         |[R]egardless of what you may think of our penal   |

|tony at tonybibbs.com |system, the fact is that every man in jail is one |

|                   |less potential fisherman to clutter up your       |

|                   |favorite pool or pond. --Ed Zern                  |

+----------------------------------------------------------------------+


--__--__--

Message: 3
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Date: Tue, 21 Oct 2003 19:19:39 -0400
Reply-To: geeklog-devel at lists.geeklog.net

Comments:

1) Block formatting:
1.1: I like the idea of being able to restrict the block formatting but not
sure how that would be implemented
Are these user preferences - I want left blocks to be 20% , center to be 40%
and right to be 40% ?
User can decide to have a 2 col view vs 3 col view

1.2: I've used several commercial portals that allow the user to control the
layout of modules or blocks on the page
pages the user can control the layout and others are defined by the admin -
so user control.
Usefull if the admin so the admin can pre-define fixed layout and then let
users add content and blocks/plugins from a library and define the layout
they want.

1.3: I like the feature we have today where I can specify the template to be
used by a block.

1.4: The template functions.php is a great concept that we have today - need
to keep this.

2) Plugin API's

2.1: Not sure we need if getSimiles() was just an example or a suggested
API.
I think we need a more generic API call that a plugin can then provide any
post-processing (as example: smilie substitution)
How about an API that was called to post-process all stories upon post,
display or preview. This may then call the registered and enabled smilie
plugin or BB-Code plugin or ImageMgmt Plugin or SpellChecker plugin.

We may need additional calls to handle the return codes from these plugin
functions should there be exceptions

2.2: Publish and Subscribe API's
GL2 Needs to have a core subscription montoring capability. Allow a user to
identify what they want to subscribe to for alerts
Plugin would then call an API to register they can provide a subscription
service. Need to think about this a bit more but the I've created a few
plugins now that duplicate this functionality.
  - Forum: Users subscribe to topics and forums they want to watch
  - Project Mgmt Plugin: Users subscribe to tasks or projects they want to
be notified of any changes
  - FileMgmt Plugin: Uses subscribe to categories or files they want to be
notified of changes

Users may want to subsribe to GL Topics or Links or Authors.

2.3: Ability for the portal to track whats changed - may be a support
function of the subscribe feature
It would be great if a member could see all that has changed since his last
visit.
Plugins would call an API to register a change  - Is this a variation of
OnEvent()

2.4) Users should be able to define how they want to be notified of
subscribed alerts or subscriptions
This may be: email, PM plugin, Instant Messenger etc ...

I'd recommend the PM function not be a Core Service but that it be a plugin
so it could be replaced. There is a need for a Core messaging service and we
can provide a PM plugin as part of the general release. But it should not be
dependant on that module and could be replaced.

What are they called - choices:
Gadgets
Modules
Blocks
Plugins
Portlets
eclips
components
xApps
microapps

I still prefer: Plugins (for integrated mini-apps) and blocks.



--__--__--

Message: 4
Date: Wed, 22 Oct 2003 09:25:08 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Geeklog 2 Module API
Reply-To: geeklog-devel at lists.geeklog.net



Blaine Lang wrote:

> Comments:

> 

> 1) Block formatting:

> 1.1: I like the idea of being able to restrict the block formatting but not

> sure how that would be implemented

> Are these user preferences - I want left blocks to be 20% , center to be 40%

> and right to be 40% ?

> User can decide to have a 2 col view vs 3 col view

> 

> 1.2: I've used several commercial portals that allow the user to control the

> layout of modules or blocks on the page

> pages the user can control the layout and others are defined by the admin -

> so user control.

> Usefull if the admin so the admin can pre-define fixed layout and then let

> users add content and blocks/plugins from a library and define the layout

> they want.


Allowing users to dynamically change the layout of a given theme is a 
difficult task.  I would prefer that the theme offer a finite set of 
choices instead.  This make the theme impelementation a little tougher 
but doesn't make the entire layout management a real nightmare.  Just my 
two cents.


> 

> 1.3: I like the feature we have today where I can specify the template to be

> used by a block.

> 

> 1.4: The template functions.php is a great concept that we have today - need

> to keep this.


Agreed to both of the above.


> 

> 2) Plugin API's

> 

> 2.1: Not sure we need if getSimiles() was just an example or a suggested

> API.

> I think we need a more generic API call that a plugin can then provide any

> post-processing (as example: smilie substitution)

> How about an API that was called to post-process all stories upon post,

> display or preview. This may then call the registered and enabled smilie

> plugin or BB-Code plugin or ImageMgmt Plugin or SpellChecker plugin.


If you look at my suggestions for event-based processing, I think you 
can get all this from that.


> 

> We may need additional calls to handle the return codes from these plugin

> functions should there be exceptions


PHP5 has exception handling built in (i.e. try and catch like Java). 
We'll plan on using that.


> 

> 2.2: Publish and Subscribe API's

> GL2 Needs to have a core subscription montoring capability. Allow a user to

> identify what they want to subscribe to for alerts

> Plugin would then call an API to register they can provide a subscription

> service. Need to think about this a bit more but the I've created a few

> plugins now that duplicate this functionality.

>   - Forum: Users subscribe to topics and forums they want to watch

>   - Project Mgmt Plugin: Users subscribe to tasks or projects they want to

> be notified of any changes

>   - FileMgmt Plugin: Uses subscribe to categories or files they want to be

> notified of changes

> 

> Users may want to subsribe to GL Topics or Links or Authors.


Anything deemed an 'item' in GL2 will give the user the ability to 
listen or watch it.  Take a look at the GL2 data model we have so far 
and look at the item and watches table.  So, in short, I think we have 
this covered.


> 

> 2.3: Ability for the portal to track whats changed - may be a support

> function of the subscribe feature

> It would be great if a member could see all that has changed since his last

> visit.

> Plugins would call an API to register a change  - Is this a variation of

> OnEvent()


Could be.  My only issue here is to be able to know what's changed since 
the last visit we would need to track when the last visit was.  Because 
we are using a custom PHP session handler I think we can work into the 
garbage collection routines that when we delete an expired session that 
we tag the last visit date/time on teh user account then.  This is good 
because it would prevent us from having to update the database on each 
page request.  As far as modules notifying one another or even GL2's 
core system we can probably plan on using the event-based stuff.


> 

> 2.4) Users should be able to define how they want to be notified of

> subscribed alerts or subscriptions

> This may be: email, PM plugin, Instant Messenger etc ...


Great idea.


> 

> I'd recommend the PM function not be a Core Service but that it be a plugin

> so it could be replaced. There is a need for a Core messaging service and we

> can provide a PM plugin as part of the general release. But it should not be

> dependant on that module and could be replaced.


When I say it is a core service I mean it will be a core module that has 
to be in place with all GL2 installations.  That way you can upgrade it 
like a module but all modules are gauranteed that the module will be 
there.  It will be important that the interface for using the messaging 
system be well thought out because if we change it then the way modules 
use it will probably change too.


> 

> What are they called - choices:

> Gadgets

> Modules

> Blocks

> Plugins

> Portlets

> eclips

> components

> xApps

> microapps

> 

> I still prefer: Plugins (for integrated mini-apps) and blocks.

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel


-- 
+----------------------------------------------------------------------+

|Tony Bibbs         |[R]egardless of what you may think of our penal   |

|tony at tonybibbs.com |system, the fact is that every man in jail is one |

|                   |less potential fisherman to clutter up your       |

|                   |favorite pool or pond. --Ed Zern                  |

+----------------------------------------------------------------------+



--__--__--

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


End of geeklog-devel Digest