To be clear, ordinary user of the dialog tools most certainly does *not*
involve knowing javascript or Lua or html.  The whole point is to arrange
that an ordinary wiki users can do wonderful things using *only wiki markup*.
(The hypothetical example of a url there is, btw, entirely wrong; but one
wouldn't write any sort of url anyway.)

The syntax for specifying a typical button would be more like
{{dialog/view|page::Name of page}}, but most people wouldn't even have to
figure that much out for themselves --- they would copy-and-modify somebody
else's markup they'd found somewhere that did something similar to what
they wanted, and they'd use common sense for how to modify it.  That's part
of the great strength of wiki markup:  you do simple things, and while
doing them you see other, slightly more advanced things that others have
done, so later on when you find you want some of those slightly more
advanced things, you've seen them before and know where to look for
examples.

Yes, there is in fact a lisp interpreter written in Lua.  It makes up for
some other weaknesses of templates.  I expect most users not to have to
touch that most of the time, and when they do they'll usually be able to
just copy others' markup and make slight, obvious modifications.  It's so
vastly handy that I've used it (you've reminded me) in some of the dialog
templates, just because it's so much easier to do things with it.  I
created it because it was obvious I'd need a powerful succinct way, without
the cumbersome notational overhead of templates or Lua (or JavaScript,
perish the thought), to specify transformations of the raw content of a
wiki page; and the one place thus far where I use it intensively is for
just such an application (removing from a wiki page all template calls of
one kind, and modifying all those of another kind).  I expect to be able to
readily build tools, using dialogs and that lisp interpreter, to do things
of the same general order as HotCat (only more sophisticated), and given
the contrast between a few lines of Lisp and the JavaScript source code for
HotCat, I think I'm quite justified in considering it an improvement... if
it proves out.  (There is some question whether this technique as currently
implemented will really scale to manipulating the whole content of large
wiki pages, due to practical limitations that may be imposed on the dialog
tools by... the template-handling of the wiki software; but we'll see at
what scale that becomes a problem, an what might be done under the hood to
move the threshold when encountered.)

I do agree that templates are rather broken, although frankly the
Foundation could --- with some deep insight --- have done things that would
have improved them.  The current plethora of magic words is a mess, partly
because the template call-syntax is heavy and pure template/magic-word
usage keeps sending things back to typeless text; both of which problems
are not shared by my embedded lisp interpreter, with it's very-low-overhead
call syntax and its simple, minimal, but highly useful dynamic type system.
_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to