Menu
▾
▴
binarycloud-dev
|
From: Justin F. <je...@ey...> - 2001-07-08 19:05:47
|
Alex:
I did a quick hack to Page to give me the ability to know
what module to talk to by giving a module a "tag", and
gaining access by using this "tag".
I am only presenting it if someone wants to keep on
writing modules and wishes to communicate between modules.
This hack is, BY NO MEANS, some sort of suggestion for
imcorporation.
The steps are:
1. Put in index.php a global array called Modules_by_tag, thus:
$Modules_by_tag = array();
// ripped from /path/to/binarycloud/user/htdocs/index.xml
$bc_page = array(
...
2. Add code in Page.php _IncludeModules($_group) thus:
...code...
foreach ($modules[$_group]['load'] as $pos=>$mod) {
import("user.mod.$mod[package].$mod[name]");
$this->modules[$_group][$pos] = new
$mod['name']($mod['options']);
#== added by jef ==
$tag = $modules[$_group]['load'][$pos]['tag'];
if (!empty($tag)) {
global $Modules_by_tag;
$Modules_by_tag[$tag] =& $this->modules[$_group][$pos];
}
#=================
4. Add 'tag' as sppropriate in index.php for a module stanza, thus:
array(
'name' => "Blank",
'package' => "lib",
'load_order' => "300",
'options' => "appears 3rd",
'tag' => "DataDictionary",
),
5. Access the tagged module properties/methods ANYWHERE thus:
global $Modules_by_tag;
$Modules_by_tag['DataDictionary']->whoami();
It works...
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: alex b. <en...@tu...> - 2001-07-08 22:31:19
|
Right, the "unique name" thing.
The problem with doing it this way (even though it works :) - is that it
relies on the user to setup module names in the page defs, instead of
providing a global, standard way of having modules communicate (and check
for communication). That adds an (as far as I am concerned) unnecessarily
complex "page setup" step which requires an developer integrating your
modules to look up Module names, put them in his/her page defs, etc. I can
see that getting unweildy very quickly.
I far prefer a MessageManager class which is capable of managing that
communication than an extension to page which allows us to name tag modules.
Any other opinions on this issue?
> I did a quick hack to Page to give me the ability to know
> what module to talk to by giving a module a "tag", and
> gaining access by using this "tag".
>
> I am only presenting it if someone wants to keep on
> writing modules and wishes to communicate between modules.
> This hack is, BY NO MEANS, some sort of suggestion for
> imcorporation.
>
> The steps are:
>
> 1. Put in index.php a global array called Modules_by_tag, thus:
>
> $Modules_by_tag = array();
> // ripped from /path/to/binarycloud/user/htdocs/index.xml
> $bc_page = array(
> ...
>
> 2. Add code in Page.php _IncludeModules($_group) thus:
> ...code...
> foreach ($modules[$_group]['load'] as $pos=>$mod) {
> import("user.mod.$mod[package].$mod[name]");
> $this->modules[$_group][$pos] = new
> $mod['name']($mod['options']);
> #== added by jef ==
> $tag = $modules[$_group]['load'][$pos]['tag'];
> if (!empty($tag)) {
> global $Modules_by_tag;
> $Modules_by_tag[$tag] =& $this->modules[$_group][$pos];
> }
> #=================
>
> 4. Add 'tag' as sppropriate in index.php for a module stanza, thus:
> array(
> 'name' => "Blank",
> 'package' => "lib",
> 'load_order' => "300",
> 'options' => "appears 3rd",
> 'tag' => "DataDictionary",
> ),
>
> 5. Access the tagged module properties/methods ANYWHERE thus:
> global $Modules_by_tag;
> $Modules_by_tag['DataDictionary']->whoami();
>
> It works...
If you were going to do this, I would suggest using an internal Page
variable, like
$Page->mod_tags['DataDictionary']->whoami();
It would not require any modification to the page def (except your addition,
which is clean) - and would not pollute the global var space.
I'm not averse to incorporating a modified version of this, simply becuase
it is effectively zero overhead, and it is nice to be able to reference a
module by name just for the hell of it.
I'll run a couple tests and see.
_alex
|
|
From: Jimmy H. <ji...@ha...> - 2001-07-10 15:52:04
|
Hi, Typically I have some code that are executed on *every* page. An example of this would be to connect to a database. I normally put them in an 'include' file and include it in all the other pages. Where would be the right place to have this "initialisation" code? I am thinking of putting it in a module, and call that module on every page, then just make a global var for the db handle e.g. global $db; and have my other modules access this $db. I somehow feel that this is not the right way to do it.... Please give me a hint thanks |
|
From: Alex B. <en...@tu...> - 2001-07-10 18:20:17
|
> Typically I have some code that are executed on *every* page. An example > of this would be to connect to a database. I normally put them in an > 'include' file and include it in all the other pages. What other things do you put in this include? All database connections will be "managed" by querymanager, based on datasource definitions that live in user/conf/datasources.xml. At the moment, Querymanager doesn't exist in the sense that it is not integrated into the system - so you'd be best off putting some of that code in a library, and include it in a module. > Where would be the right place to have this "initialisation" code? > > I am thinking of putting it in a module, and call that module on every > page, then just make a global var for the db handle e.g. global $db; and > have my other modules access this $db. > > I somehow feel that this is not the right way to do it.... While r2 is in development, it is. When all the tools are hooked up, etc you won't want to do it that way, because it will be 100x easier to use QM. _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
Thanks for helping keep SourceForge clean.
X