2011/1/25 Jesse (Pathoschild) <pathoschild(a)gmail.com>
On Tue, Jan 25, 2011 at 8:14 AM, Alex Brollo
<alex.brollo(a)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/LabeledSectionTr…
.
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