Re: [Simplog-devel] update

[Jeremy A. <ash...@13...>]

Jim Hu wrote:

> I've looked at it, and the modifications you made make sense to me.  
> I'm assuming that for now we are not requiring php5.  

nope...just remember this code was just a way to prove that my framework 
idea actually worked, not to be the base to start development 
from......nothing is set in stone.....

> Here are some half-baked thoughts:
>
> 1) I'm wondering if there might be a way to eliminate the global 
> variables $event_table and $modlist (should it be $mod_list?) by 
> either including them in class Collection, or by making class 
> ModuleCollection extends Collection, so that a new ModuleCollection 
> object loads the modules and registers their actions.  

We'd still have to have global object to accessm so I don't see anything 
wrong with them.

> The constructor for ModuleCollection could include a path so that a 
> subset of the modules in the modules directory could be loaded if 
> specified, or the default would be everything or nothing.  I'd like to 
> see this set up so that we could do something like this:
>
> $myModules = new ModuleCollection()
> $myModules-> loadmodules(path1);
> $myModules-> loadmodules(path2);
>
> etc. so that different subsets could be loaded, appending to the list 
> of event handlers.  This will come in handy when we want to pull which 
> module packages to load for individual users, or different blogs - 
> which I'm thinking will ultimately be stored somewhere in the 
> database.  I'm imagining that a module manager something like the 
> current blocksadmin would let users move modules up and down their 
> individualized priority lists.
>
I think that modules should be administered by the superuser and 
available across all blogs and available to all users.  Mmodules are a 
system level feature, not a blog level piece.  Individual blog 
customization shouldl come from more detailed blog level configuration 
and a good templating system.

> We need to control how many handlers are allowed to respond to an 
> event.  For example, different blogs running from a single install 
> will have different headers, and trigger("header") should only do one 
> per blog...but we want to allow different kinds of header modules to 
> coexist in a single installation.  This could be done by passing an 
> integer to trigger that determines how many to run.  Or perhaps this 
> should be controlled by an associative array of event types: 
> $do_trigger['header'] = 1; $do_trigger['blocks'] = 0; # 0 means do all 
> available.
>
triggering an event should call all module methods that have registered 
for that event.  That's the whole point of having the callback system.  
We shouldn;t limit the number of methods that respond to that event.  
The module system is for easily adding functionality to blogging engine 
as a whole, not for blog level tweaking and customizing. 

> 2) I think that the do module code in index.php should be rolled into 
> a common function.
>
me too, i was just being lazy :)

> 3) For purposes of inter-module communication, I think that modules 
> should never print or echo directly - they have methods that a) print 
> and b) return string variables or false for another module to use as 
> input.
>
agreed, again, me being lazy

> 4) I'd make common.php a modules.php file within a subdirectory called 
> common, or functions, or something like that.  I'm assuming that 
> despite the OO redesign, some common use functions will still be in 
> the equivalent of the current lib.php.  I think lib.php is a bit 
> awkward as it's set up now, and dividing it into different functional 
> groups in different files might make life easier.
>
yep, i think there will end up being a common or includes dir with all 
the shared function libs in it

> 5) Unrelated to the OO design, but I'm wondering if we can change the 
> way permalink and archive URL paths are set up so that it's easier for 
> technorati to index our blogs.  Well, actually this may be related to 
> OO, since I'm not sure this would be the same on Apache vs. other 
> servers, so perhaps different modules would be used depending on the 
> server software.
>
the entry URLs will change, and i'm thinking on making them more search 
engine friendly,  it'll break the old URLs and GUIDs in the syndication 
feeds, but oh well.....I've been thinking of doing some URL rewriting 
with mod_rewite (sorry non-apache folks) to have nice readable urls like 
http://www.simplog.org/1/blog/add or http://www.simplog.org/1/view/32, 
or something like that

I really like some of the stuff drupal is doing with their 
architechture.  it'd be worth looking at what their doing to steal some 
ideas....
http://www.drupal.org and http://www.drupaldocs.org