|
From: alex b. <en...@tu...> - 2001-07-08 18:17:15
|
> Nope, nada, niente, pas de tout, is
> load_order having _ANY_ effect on the
> disto index.php.
It works like a charm for me? Has done since the first crappy pseudocode
version of Page that I wrote :)
> then the load order still follows the order of the
> module appearance in index.php, instead of
> the appearance to load_order of
YES! but that isn't load order.
remember that _load_ (i.e. instantiation) order is _totally_different_ from
output order, which is just the order that you define the modules in the
page definition.
it is necessary to have the two abstracted - so you can do a query that may
affect another module _first_, but send output "last"
> which means it is not sorting, but following appearance order.
> I even added your ksort fix in Page.php where you said it
> should go, and it still just follows appearance order.
Look at this array:
[Page] => page Object
(
[title] => binarycloud page title <-- I added the title, btw :)
[modules] => Array
(
[content] => Array
(
[2] => helloworld Object
(
[options] => Array
(
[example] => this is an option
value
[another] => 1
)
[date] => Jul:Sun:2001
)
[5] => helloworld Object
(
[options] =>
[date] => Jul:Sun:2001
)
[0] => otherworld Object
(
[stuff] => This is some sample stuff
)
[4] => helloworld Object
(
[options] =>
[date] => Jul:Sun:2001
)
[3] => helloworld Object
(
[options] =>
[date] => Jul:Sun:2001
)
[1] => set_lang_example Object
(
)
)
***
Note how the above is sorted by _output_ order, but the array kays are
_load_ order.
in Page, output is done by just looping through $this->modules, whereas
instantiation is done by sorting on the array keys.
[left] => Array
(
[1] => helloworld Object
(
[options] =>
[date] => Jul:Sun:2001
)
[0] => helloworld Object
(
[options] =>
[date] => Jul:Sun:2001
)
)
)
Same here.
_a
|