Thread:DoCheonGong/@comment-3225604-20160608091907/@comment-26235098-20160624074254

Imamadmad wrote: Just thinking here, and this idea could be much too radical and time-consuming to create, but how about we create a module which stores all information about levels in a table, where the key to the main table is the level number and the value is another table with values for if it's a dreamworld level, its episode, type, moves, goal, etc, and then another module can call that information and iterate over the list to populate the tables seen in the "List of *" pages, similar to how a framework such as Node.js or Flask would populate an HTML table with information from a database/JSON file? The benefit there would be that the "database" of level information can be called from all different places and would mean that we keep all information on a level in a centralised location, rather than spread across level pages, list of level pages, etc. Also, by rejigging the "List of *" pages completely, we can put the handling for split levels directly in the table creating Lua script. Feasible, or would it cause too much overhead to page load times do you think? I'm happy to try out a proof-of-concept prototype if you want, since I've got some free time over the next few weeks.

I actually had exactly the same thought, and was going to try implementing a portion, mostly to check performance - if you want to do a proof of concept first that sounds good. We can check performance with fake/replicated data too to see how much it can handle.

The main reason I see to do this (and IMHO a good reason) would be that the information is present only once - this would enforce consistency between the main list of levels and each of the "typed" list of levels... and any other list of levels I might be overlooking.

Considering performance and data heterogeneity across level types, DW & R, we may want to consider a structured split:
 * a master table - that containing ALL levels, but without properties, that points to the detailed table in for each level.
 * separate level detail tables between Realit and DW, and for each type.

Splitting is advantageous for editability, but the structured splitting would not improve performance on the "big" list of levels.

If performance is an issue, another option would be to split similarly to the page/display table sections themselves: dreamworld and reality separate, worlds or at least chunks of levels separate. However, but there's an advantage to having at least a master lookup (index) if not a giant table with everything.

Also, I wonder if your bot could be used to create the tables by harvesting the data from the main List of Levels/World ... pages?

GETTING EVEN MORE COMPLICATED: I had another idea too -- which is basically that what we need here is a database. Coz that's kinda the concept we're chasing with iterating tables in Lua. Now, I do think this might be overkill, lol, in terms of work, and I don't know the feasibility -- maybe you do? stick all this stuff in a DB? and write lua to query it? I think the MySQL db is available as an option. But here now I worry about editability.. IDK if the mediawiki support offers a built in UI for ppl to edit values (like a form-based thing, so ppl don't have to know SQL to update/insert new values. If there is no front end, this would be a loooooooooooooott of work as we'd have to write one, otherwise it would not be "usable" enough for normal users. Do you know anything about plugging MySQL into a wiki?  What do you think... overkill regardless, or worth investigating?

BACK TO BASICS: For the moment, I did write wrappers for handling each line just at template level, which checks for spliting just once per line, so this "simpler" option would be available in a day or so. The per-line template would handle all the list-of tables - some params are optional, but I still have to test it. I am happy to leave this as a "fallback" solution, in case we run into unexpected issues with the Lua megatable idea.