There are a lot of apparent benefits to doing it all in Javascript, but
it still bothers me because it's a huge violation of Don't Repeat Yourself.
You're probably right that we will want a wikitext parser on the client
someday, especially for the editor. So perhaps I'm struggling for no
good reason.
But, duplicating all the parser functionality *and* transferring the
entire state of the MediaWiki server to the client still seems like the
wrong thing.
I have some more radical ideas like making the parser emit JS closures
when appropriate, but those are probably even more unrealistic until
Niklaus' new Message class lands (and maybe not even then).
Anyway, after denting my head on my desk a few times I'm starting to
think that wfMsg* is just unworkable for this idea.
So unless anyone else has any bright ideas I'll just give up and go with
Michael Dale's approach of sending a parser along, at least for now.
On 8/11/10 1:39 AM, Michael Dale wrote:
On 08/10/2010 07:01 PM, Neil Kandalgaonkar wrote:
OPTION 2:
Figure out some way to alter parsing on the server for Javascript
messages, such that things like {{SITENAME}} are parsed, but
{{PLURAL}} isn't (or, the parse results emits an identical {{PLURAL}}
template call).
Then a much simpler parser -- probably based on regular expressions --
can be deployed to the client.
Roan Kattouw and Trevor Parscal are working on a new Resource Loader
that may be able to do some of the above. Also, Niklaus Laxstrom is
working on a new Message class that looks like it will be far more
amenable to this sort of thing.
One potential problems with simple regex is msg key values like:
'category-subcat-count' => '{{PLURAL:$2|This category has only the
following subcategory.|This category has the following
{{PLURAL:$1|subcategory|$1 subcategories}}, out of $2 total.}}
If you can do a regEx that will work for such substitution that would be
great, or the server could do some transform that represented the
transforms in JSON so that the template parsing could be avoided .. ( If
thats the goal ) then it could relatively easily be done that way. The
JSON representation the server creates ends up looking a lot like the
intermediate object the client side template parser creates ( more
verbose than the wikitext )... or ... we can just do the template
parsing in javascript.
I went with the client side template parsing route with the idea that we
will eventually find other uses for client side wikitext template
parser, and we could refine and built a relatively robust components for
handling wikitext on the client. While its not fun to maintain "two
parsers" its also not fun to maintain two data representation formats.
i.e I don't know how well suited the existing php based parser
"infastructure" is for intermediate JSON representation, and we will
have to matain a JSON transform library in php and associated JSON ->
html / interface(s) & JSON-> wikitext in javascript. Depending on the
type of applications built handling some of the wikitext parsing in
javascript could be more server side resource friendly.
I liked the idea that we briefly discussed in person that javascript
modules can include an additional mw.wiktextLangauge module in their
dependency list if they use message template substitution, while the
base javascript library just includes vanilla substitution.
The mw.parser would be a required dependency of the wiktextLangauge module.
The basic rule for server side template expansion vs client side parsing
is a variable argument. If you have
{{PLURAL:{{NUMBEROFEDITS}}|edit|edits}} there is no reason to not swap
in "edits" on the server for that message. Of course managing expiration
of magic substation is already 'no fun' with use in wikitext so people
should be discouraged from going crazy with these things inside message
values.
In general direct substitutions like {{SITENAME}} should move towards
normal $1 substitution with a uniform way to package php variables into
javascript. What presently is
<script type="text/javascript">/*<![CDATA[*/
var wgArticlePath = "/wiki/$1";
var wgScriptPath = "/w"; .. etc
Should instead be a set of variables exported via the resource loader
for specific modules. Ie MakeGlobalVariablesScript hook should be
replaced with something a bit more intelligent that allows for the
resource loader manifests to specify what variables it needs.
Ideally these variables get packaged via mw.setConfig / mw.getConfig
rather than plopped into the global namespace.
Since the resource loader will be pre-processing all the javascript
there (eventually ) will be no reason to define all these variables
globally which presently makes it impossible to send loggin users the
same cached page as anymous users. ( ie user specif variables should be
a different url than site / page specif exported variables ) This also
lets you change configuration without purging the javascript code cache
if thats a desirable feature.
In the dynamic loading context its a bit more tricky to not pollute the
cache, but the dynamic loading resource loader code could just issue a
separate parallel request for such associated JavaScript resource
packaged configuration / exported variables where needed. Possibly
packaged with the messages if it turns out messages / configuration
change more frequently then source code and you don't want one mangling
the cache of the other.
--michael
--
Neil Kandalgaonkar <neilk(a)wikimedia.org>