> > You can already use subpages to store data. Access is then O(1) The > "problem" is that then you have one page per entry.
I know. What I'm suggesting is an interface where the sub-pages aggregate up the hierarchy, meaning you can still edit the main top-level page, and the backend will simply update the sub-pages as appropriate. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | [email protected] On Tue, Feb 19, 2013 at 5:52 PM, Platonides <[email protected]> wrote: > On 19/02/13 13:56, Tyler Romeo wrote: > > So unfortunately I don't have a clear idea of what the problem is, > > primarily because I don't know anything about the Parser and its inner > > workings, but as far as having all the data in one page, here's > something. > > Maybe this is a bad idea, but how about having a PHP-array content type. > In > > other words, MyNamespace:MyPage would render the entire data structure, > but > > MyNamespace:MyPage/index/test/0 would take $arr['index']['test'][0]. In > the > > database, it would be stored as individual sub-pages, and leaf sub-pages > > would render exactly like a normal page would, but non-leaf pages would > > build the array from all child sub-pages and display it to the user. > Would > > this solve the problem? Because if so, I've put some thought into it and > > would be willing to maybe draft an extension giving such a capability. > > You can already use subpages to store data. Access is then O(1) The > "problem" is that then you have one page per entry. > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
