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 | tylerromeo@gmail.com
On Tue, Feb 19, 2013 at 5:52 PM, Platonides Platonides@gmail.com 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l