2009/9/26 Brian <Brian.Mingus(a)colorado.edu>du>:
Roan, sorry that the idea is pretty hard to convey,
I'll try again.
The basic idea is that you can create templates using templates
(just using current
tech). It's easy, you just pass parameters to a template that control
its output, and this
output is a new template. The parameters that you passed determine what the
new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates,
right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is
used to generate all
infoboxes. It could work in arbitrary ways, but suppose it works this way:
The master infobox template creates a template for each wikiproject. The
template that it creates for each wikiproject further creates templates
representing every kind of infobox that this wikiproject uses. So you have a
master template that creates baby templates that create infobox templates.
Using current tech this isn't exactly feasible, only advanced users will do
it since you have to directly interact with the templates and it would be
tough to code up. But if you make such a feature highly usable, by, for
example, tacking an easy to use interface on top of it, the usage of such
techniques will proliferate.
To use the master infobox example: such a template would have about a
dozen usage modes, each with dozens of parameters. Such constructs are
actually /easier/ to call by hand than with a form, because you'd
either have to store all the relationships between the parameters and
usage modes in the XML file and let the form handle all that (which is
a degree of complexity I personally would not like to see in a
template forms implementation) or just throw a couple hundred
parameters in the user's face.
Also, this being tough to code up would not change: again, we're not
simplifying the *writing* of templates *themselves* in any way. The
fact that these templates include template calls doesn't change that,
because 1) you're gonna be using #if constructs all over the place
anyway, 2) you'd need to use stuff like {{{2|{{{1|}}}}}} as arguments
to template calls, which the GUI doesn't simplify and 3) if you're
skilled enough to do 1 and 2 and familiar enough with the templates
you're calling to be writing a master templates, you don't need an
editor or form to build the template calls for you.
More general kinds of interface builders that build
all imaginable kinds of
interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system.
You don't /need/ a template editor to be doing this kind of monkey
business. In fact, I think a template editor would actually discourage
these practices, because relatively unexperienced users must be able
to build a reasonable template call using the template editor. For the
latter to work out, templates need to be simpler rather than more
complex.
In short, I don't think introducing a template editor would encourage
master templates and similar complexification of templates; in fact, I
believe it will actually encourage simplification, because a
nice-looking GUI for a big incomprehensible parameter soup is worth
the soup.
Roan Kattouw (Catrope)