[geeklog-devel] Re: Geeklog 2 Module API

[Tony Bibbs]

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