"Modular site" mod writers name vars or use ident supplied by app

[Tyno Gendo]

I'm writing a test "modular site". So far I have created an App class,
a Module Manager class and a couple of test modules.

The Manager looks in a directory called 'modules' and then for every
..php file is try to create a class of type <filenameminu s the .php, so
eg. for testmodule.php it tries to create a class "testmodule " and puts
it into an array within the module manager called $_modules

Module Manager has a dispatch_messag e function which accepts an ID for
the type of message to send, which recurses through the modules in
$_modules and uses their ReceiveMessage function to send them the message.

example:

public function dispatch_messag e( $message_id ) {
foreach ( $this->_modules as $module ) {
$module->ReceiveMessage ( $message_id );
}
}

This is all working well and good, the thing I'm wondering about is when
modules want to postback information, should i rely on module users
naming their form inputs specifically to their module, or should my app
(when register the modules) supply a module with a unique 'ident' that
the module writer should then check for in their code and all for in
their forms etc.

eg., should i force module writers to make forms as such:

<input type="text" name="<?phpecho $mymodules->ident()?>_user name"
value="" />

How do these modular sites normally differentiate from one modules POSt
to anothers?

[Toby A Inkster]

Tyno Gendo wrote:

should i rely on module users naming their form inputs specifically to
their module, or should my app (when register the modules) supply a
module with a unique 'ident' that the module writer should then check
for in their code and all for in their forms etc.

The latter route sounds like a good idea. For my current project though, I
went the former route, though in my API document, I've described a naming
convention (similar to the naming convention used by Java packages) to
avoid naming collisions between different modules.

The convention is like this: say I'm writing a module that does "foo" for
the package, and I own the domain name "tobyinkster.co .uk", then I'd name
my module:

uk_co_tobyinkst er_foo

If my module needed to create, say, form input fields, it would make sure
they used "uk_co_tobyinks ter_foo" as a prefix for the field names. If it
wanted to generate some HTML output using some "class" or "id" attributes,
then it would similarly prefix them.

If a module user didn't own their own domain name, they could simply use
their e-mail address:

com_hotmail_at_ joebloggs_foo

Although you do end up with some fairly ugly-looking module names, this is
a pretty sure-fire way to avoid naming collisions. Because of the ugly
names, in my plugin registration function, I do allow plugin authors to
provide a "friendly" name for their plugin, which is displayed anywhere a
user is likely to see it. I also allow them to provide a link, the author's
name, some version information and so on.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[Tyno Gendo]

Toby A Inkster wrote:
<snip>

If a module user didn't own their own domain name, they could simply use
their e-mail address:

com_hotmail_at_ joebloggs_foo

Although you do end up with some fairly ugly-looking module names, this is
a pretty sure-fire way to avoid naming collisions. Because of the ugly
names, in my plugin registration function, I do allow plugin authors to
provide a "friendly" name for their plugin, which is displayed anywhere a
user is likely to see it. I also allow them to provide a link, the author's
name, some version information and so on.

Thanks for that reply, useful. I think I will go with supplying an
ident to each module as it registers, using the code from uniqid example:

$ident = md5(uniqid(rand (), true));

This will created the ident and call the module (see below) on creation
with $module->SetModuleIdent ifier($ident);

Then a module writer can use the ident as prefix to forms/session values
etc.

PRESENTATION
------------

What's the best way of handling where a module loads in terms of
presentation??? I notice most "modular" sites has presentation areas,
such as header, menu, user_menu, footers etc.

So best way to handle is to have a module specify where it wants to
appear on creation???

eg. test module below should have something like the following which the
module registration utiltity could call after creation to find out where
this modules sits???

function GetPlacement() {
return OBJ_PLACEMENT_U SERMENU;
}
MESSAGING VS. HOOKS??
---------------------

I was thinking of using a messaging system to alert modules that they an
event has happened but other people seem to have a hook's based system
where modules say they want to handle an event in advance, what's the
pro's and con's ??

I'm thinking of handling like so:

<?php
class testmodule {

function SetModuleIdenti fier( $id ) {
// TODO:
}

function ReceiveMessage( $messageid ) { TODO: add $params

switch($message id) {

case MSG_APPLICATION _PAGELOAD:
echo "Hello from module 1!\n";
break;

case MSG_APPLICATION _PAGERENDER:
if ( $_SERVER["REQUEST_METHOD "]<>"POST" ) {
?>
<p>
<form action="<?php echo $_SERVER["PHP_SELF"]?>"
method="post">
Please chose a registered name
<input type="text" name="username" value="" />
<input type="submit" name="submit" />
</form>
</p>
<?php
}
else {
?>
<p>
You chose the registered name <?php echo
$_POST["username"]; ?>
</p>
<?php
}
break;

case MSG_APPLICATION _PAGEUNLOAD:
echo "Goodbye!\n ";
break;

}

}

}
?>