Re: [binarycloud-dev] (REDUX) Still Something Rotten....

[Justin F. <je...@ey...>]

Odysseas:

Thanks Odysseas for making this "official".  I did
go in and var_dump() stuff in Page to see what was really
happening before and after uasort() and the added ksort().
There is still that lingering aspect of
"easy" confusion between "load_order" really meaning,
for me, "instantiation order", and having nothing to
to with "loading order" into the output buffer.
So, in any case, rendering will take place in
appearance order, unless you specifically change it
with a layout template.

Still, WHAT I CONSIDER UNACCEPTABLE, in the current
state of affairs, is the near-complete loss of generality
of writing modules if you wish to communicate with
other modules.  If you do not put things into
global scope, one must know, apriori, for any
module, what the appearance order in $bc_page
is for the other module to communicate with since
the suggested idiom is:

$Page->modules['group_name'][2]->get_lookup_table()

to avoid going into global scope.  General modules
will have no idea, aprior, where to look for a
particular lookup table, for example, unless one
establishes a convention that, say, a lookuptable
module is _always_ put into a group named something
that is apriori agreed upon, and will be the only module
in that group.  In that cumbersome way, you can
count on finding, say, the data dictionary in the
module in the 'data_dictionary' group, at index
zero, thus:

$Page->modules['data_dictionary'][0]->get_data()

So the conventions would have to be, for modules
that wish to talk, or expose their properties/methods,
would cause the conflicting requirements of

1.  Loading in a unique group.
2.  Being the only module in that group
3.  Having to write a layout template to cause
	output to be rendered in a potentially
	spaghetti order, instead of the
	appearance order.
4.  Potentially many module groups

There are workarounds to this problem of discovering
the module that you wish to talk to, if the communicant
module appearance/group is not known apriori.  Such
workarounds that I have thought of, to at least use
temporarily until some kind of better facility is
built in, is to add something to $bc_page like,

   array(
            'name'          => "EyeLibrary", 
            'package'       => "lib",     
            'load_order'    => "100",
            'options'       => "appears 2",
            'tag'           => "MySQL_data_dictionary',
    ),

and then go traverse the $bc_page tree until you find the
tag "MySQL_data_dictionary", and having kept track of the
['group_name'] and appearance order, then one could talk
like:

$Page->modules['group_name_found'][$idx_found]->get_data_dictionary();

THIS IS EXPENSIVE.

Now I am working/tinkering on something else in $Page, and
probably wasting my time, whereby, using that-there
completely_unofficial_tag as above, any module can call

$Page->modules_by_tag['tag_wanted']->get_data_dictionary()

without having to know, apriori, where the hell that
module lives in the $Page->modules[] array.

According to Alex, some kind of Manager is contemplated
to reduce this intercommunication set of problems to
something simple...

In the mean time, I want to continue writing modules,
and I am depending on intercommunication, so I may just
hack something to allow me to keep on a-goin'.  Or,
just sin, and put things in global scope, and keep on
a-goin'.


_jef_the_sinner

PS:  I find it interesting that youse guys are into this
with a kind of mindset that a module is a_kind_of_standalone_application
and Jason and I went into this with a kind of mindset of
a module is an itty-bitty piece of Lego_which_has_to_communicate...
We are atomic physicists, and you are molecular biologists ;)
---
Odysseas Tsatalos wrote:
> 
> The load_order defines the order of module
> instantiation (mnemonic: instantiation == loading) not
> the order of display.
> The order of display is the same as the order of
> appearence in the index.php.
> So after you run _IncludeModules
> the
> 
> $Page->modules['content']
> 
> order should be (as you noticed) the same as the order
> of appearence.
> The default layout will simply iterate over that
> array outputing the cached output of each module
> and that will produce the desired result.
> 
> In order to see the actual order of modules
> instantiation just stick a debugging stmt in the for
> loop (function _IncludeModules), right after the
> instantiation:
> 
>         foreach ($modules[$_group]['load'] as
> $pos=>$mod) {
> 
> import("user.mod.$mod[package].$mod[name]");
>             $this->modules[$_group][$pos] = new
> $mod['name']($mod['options']);
>             echo("group: $_group, module
> $mod[name]\n");
>         }
> 
> You will see your debugging output right above the
> binarycloud image.
> 
> odysseas
------

-- 
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722