History: DaytonTikiCore
Preview of version: 5
Folks,
I thinks it's a little rude to post a large message to an entire list. So
apologize. But I discovered as I was trying to do "important" stuff this
morning that I couldn't do anything until I wrote this. And being a novice
at wiki (and tiki) I figured that making a wiki page would add a couple of
hours to the task. Again I apologize for side-stepping the (good) tiki
custom of writing to the website.
The following is a somewhat detailed presentation of what I've done while
implementing my extension to tiki (called handin). I've read some (if not
all) the wiki pages on the core. This is not meant to address them point by
point but it does cover many of the issues raised in them.
Well, I'm off to do "important" things. I'll return in several hours and
try to get on the IRC channel.
dayton
1) There will be a directory in the tiki root (I'll use tiki) called 'tiki/ext'. And a database,
'tiki_extensions'. The database will include fields covering:
o Is this extension active and for what tiki groups.
o The extension handle (i.e. the subdirectory name, see below).
o The installed version of the extension.
o Required tiki version.
o Other dependencies (how this is specified I don't know)
o Person responsible locally for maintenance of the extension
w/contact information.
o Contact information for the developer or global maintainers.
o Documentation url.
2) Code for the extension resides in a subdirectory of tiki/ext with the
name of it's handle from the database. The extension I'm working on is
called 'handin' so I'll use that for examples.
In tiki/ext/handin is a script 'handin-install.php'. This script checks
if the extension is installed and if so what version is installed. The
script then handles the installation or upgrade as appropriate. I
suppose that the default for a fresh install is that the extension is
only active for the admin group.
This way, installation is basically a matter of putting the code in
place and invoking handin-install.php. Note that installation may
involve creating modules and menus and other stuff in addition to
putting it's entry in tiki_extensions.
Maybe it should be the responsiblity of handin-install.php to check for
dependencies and fail if things aren't right. This is cleaner than
specifying in the database and trying to maintain dependencies on the
tiki-core level. I like this better.
I suppose there should also be scripts, handin-disable.php,
handin-enable.php, and handin-uninstall.php which do the appropriate
thing.
3) The API for extensions is via callouts. There is a database
'tiki_callouts' with the following fields (excues me, I should say
columns):
o 'extension' is the handle of the extension which put this in the
database.
o 'location' specifies where the callout should be invoked. The
core will have statements like
$tikiCallouts->doCallouts('post-setup');
where $tikiCallouts is an object of class Callouts created early
in the setup process. The string 'post-setup' specifies the
location of the callout. This particular example is at the end
of tiki-setup.php.
o 'action' which is a text string of upto 255 characters. This is
either the name of a file to include or a php command.
o 'sequence' which is an integer that specifies the order actions
should be invoked for this extension if the extension specifies
more than one action for a location. Maybe this provides too
much flexibility.
o There might be other columns like 'installation-date' and columns
for statistics like how many times the callout is invoked.
So now when $tikiCallouts->doCallouts('post-setup') is invoked it
searches tiki_callouts for all rows with `location` = "post-setup". For
each row found, the 'action' is performed or included as appropriate.
Order is important here and I'm not sure how to specify the order
between extensions. Perhaps each extension should have an 'order
number' which specifies its relationship to other extensions, but who
sets it? What about cycles? (i.e., extA callouts should precede extB
callouts which should precede extC callouts which should precede extA
callouts). For a start we can say that the order is static and the
extension's install script and/or the local admin is responsible for
setting it.
At the end of this message I've included my code for the class Callouts.
Note that my current implementations differs some from what I've
described above.
4) This is an idea that came to me last night (I have dreams
about tiki!) so I haven't had a chance to test it at all.
A script, tiki-ext.php, is used to invoke extension scripts. So that:
http://my.host/tiki/tiki-ext.php?e=handin;s=handinHomePage.php
would invoke tiki-ext.php which would in the end
require(ext/handin/handinHomePage.php);
This appeals to me for several reasons:
o tiki-ext.php can handle the setup of the environment
(tiki-setup.php etc.) so the extension script need not do this.
o The extension scripts can be concealed from the web directly via
.htaccess or similar techniques.
o tiki-ext.php can provide sanity checking, permissons checking,
security, and statistics gathering. This and the above could
make the site a little less dependent on the security of
the extension's code.
Well that's about it. I can already think of modifications and objections
(e.g., group permissions should be on the per callout basis and not a per
extension basis.) But it's something to consider.
Now some code. Here's a summary of what I've done for the handin extension
so far. My existing code varies from what I've described above, but similar
enough to give you the feeling for what I've done.
In tiki-init.php (invoked at basically the same time as db/local.php, I like
this scheme but am not married to it). I have
/* How were we invoked.
*/
$uri = $_SERVER'REQUEST_URI';
{
$tikidomain = 'dayton';
}