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