2011/1/25 Jesse (Pathoschild) pathoschild@gmail.com
On Tue, Jan 25, 2011 at 8:14 AM, Alex Brollo alex.brollo@gmail.com wrote:
If this would happen, I imagine that the original page could be
considered
an "object", t.i. a collection of "attributes" (fragments of text) and "methods" (template chunks).
Labeled Section Transclusion can be used this way, but it's not very efficient for this. Internally it uses generated regular expressions to extract sections; you can peek at its source code at < http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/LabeledSectionTra...
.
Thanks, but I'm far from understanding such a php code, nor I have any idea about the "whole exotic thing" of wiki code parsing and html generation. But, if I'd write something like #lst, I'd index text using section code simply as delimiters, building something hidden like this into the wiki code ot into another field of database:
<!-- sections s1[0:100] s2 [120:20] s3[200:150] -->
where s1,s2,s3 are the section names and numbers the offset/length of the text between section tags into the wiki page "string"; or something similar to this, built to be extremely simple/fast to parse and to give back substrings of the page in the fastest, most efficient way. Such data should be calculated only when a page content is changed. I guess, that efficiency of sections would increase a lot, incouraging a larger use of #lst.
If such parsing of section text would be the first step of page parsing, even segments of text delimited by noinclude tags could be retrieved.
Alex