https://bugzilla.wikimedia.org/show_bug.cgi?id=26092
--- Comment #31 from Rich Farmbrough <rich...@farmbrough.co.uk> 2011-02-14
14:55:31 UTC ---
I find Mark's confusion only too understandable.
The thrust of the argument against providing extended parser functions (and
most other string handling possibilities) seems to be "people will use them"
and cause performance problems. This is a form of dynamical system - the more
facilities you provide the more are used, until a problem is hit. From the
point of view of - say - rendering time, or expanded size or some other metric,
the community receives a new, more efficient tool, and after a period of time
the rendering times are back to what they were before. So if you are running
the servers you might say "nothing gained". But in fact, functionality has
been gained. Look if you will at
[[en:Template:Monthly clean-up category]]
If you want to create a monthly clean-up category you stick this template on
the page and that's it. No paramters. No cats. No Defaultsort. No tag, boxes,
typing, just "Edit" ctrl V alt-shift-s.
That is productivity, that means we have more time for other stuff. And since
the pages are behind the scenes, the render time isn't critical (but I'll bet
it's pretty quick anyway, and with Wikkd (sp's) speedups could be quicker).
Now there is no reason this sort of functionality shouldn't be used to parse
template arguments. I cannot, for example, reliably remove [[]] from a
parameter. This means the only solution to the "link or not" dilemma is to not
link, and enforce that by bot, or using string functions to spot the "[", and
then use "autolink" which invokes ifexists which (we are told) is an
"expensive parser function" (why it's expensive is a mystery, it should be much
cheaper to find if something exists than to transclude it, since transclusion
needs to determine if the thing exists anyway).
The recursive {{}} (which are not recursive) are not really a problem, the
problem lies with the fact that some of the core or widely used templates are
inefficient - I plead guilty to adding a few symbols to {{yesno}} many moons
ago, which probably get evaluated several hundreds of millions of times a day.
But for "deep template magic" I don't really care where the functionality or
performance comes from - I could suggest a hashed lookup table might be a great
boost, for example - I just want to be able to use the sub-template
[[en:Template:Page numbers]] in the cite family without killing pages.
Good software engineering practice is to validate your inputs, we don't have
that luxury without simple string handling.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
