While exploring features of Labeled Section Transclusion Extension, mainly
used into source projects as a tool for proofread procedure, I found that
the extensione could solve many issues completely unrelated with such
procedure, but I found too some liminations coming IMHO from the way it is
implemented into the parsing path of the raw text of the page.
1. I can't transclude raw text wrapped into a template call: this doesn't
run:
{{center|<section begin=1 />Text<section end=1 />}}
2. I can't transclude raw text wrapped into a HTML comment like this:
<!--<section begin=1 />Text<section end=1 />-->
3. I can't transclude raw text wrapped into a noinclude tag:
<noinclude><section begin=1 />Text<section end=1 /></noinclude>
4. I can't transclude text coming from the same page calling transclusion.
I can't read php parsing scripts, but I can imagine that that thing will
change if labeled transclusion would be simply built as a regex search into
the raw code of the page, ignoring any other content of such raw code; and I
can imagine too that a great improvement in performance should be gained if
the page to search in would be kept into memory or into a fast cache,
allowing multiple labeled section searches into the same page without the
need of reloading it.
If #lst would be converted in a fast, effective, simple code including tool,
lots of interesting results should IMHO be gained: templates could be
converted into "libraries"; mono-and multidimensional arrays could be easily
used; a undetermined number of "variables" could be loaded and used easily;
redundance and coherence of data and metadata could be gained. Most
interesting, nothing of usual #lst syntax would need a change.
Is there any major drawback in such an idea?
Alex brollo