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 |