tparscal at wikimedia
Sep 6, 2011, 10:04 AM
Post #2 of 16
I wrote a node.js module, which could easily be ported to PHP, which uses
Re: Taking suggestions for a template language syntax for our skin system
[In reply to]
DOM on the server to pre-process HTML, acting on some specific tags and
resulting in clean HTML output. This only works for HTML, so I don't know
about your requirements of being able to do this in inline CSS as well, but
it's an approach that may work well with MediaWiki. I'm using JSDom in
HTMLDocument could work too.
The concept is similar to, and based on my jquery.localize plugin, just a
bit more powerful. I think it could be extended to support a variety of
<var:attr set="lang" from="user.lang"></var:attr>
fallback for missing message
<var:text>fallback for missing variable</var:text>
<tpl:apply from="foo">fallback for missing template</tpl:apply>
There are some other features, but that's generally how it works. Tags in
the tpl, msg and var namespaces are handled specially. tpl is a way to
define and apply snippets of HTML with preprocessing instructions. msg is a
way to grab messages from the localization system, and supports parameters.
I think the "magic" way of knowing to escape HTML could be applied as well I
suppose, rather than explicitly using :html and :text - I chose explicit
because I think it makes it easier to review, magic goes unnoticed more
Anyways, just offering up a possible idea - sounds like you have some really
specific wants and needs, which may or may not really be common in
mainstream MediaWiki development.
On Mon, Sep 5, 2011 at 11:27 PM, Daniel Friesen
<lists [at] nadir-seen-fire>wrote:
> One of the things I believe we're missing from our skin system is a
> template language.
> PHP embedding is excessively verbose, and it makes it impossible to
> contemplate letting users upload skins at whim in a farm scenario.
> There are also other things we can't do with php that we can do with a
> template language, such as preprocessing the template and extracting
> information about the skin that would've required extra config, and
> using that as an advantage that lets us keep backwards compatibility
> based on what a skin has left out while adding new features (eg: adding
> a pageicons area, but detecting old skins that don't have these and
> instead automatically combining it with the title key).
> As I see it a good template language for us would need to have the
> following requirements:
> - No evalable php in the syntax. Such a thing would nearly preclude the
> safe-skins only scenario.
> - We should be able to analyze a template; ie: The syntax should not be
> one that prevents us from knowing beforehand what 'region' tags are in a
> template, or if say a 'pageicon' key is omitted.
> - The syntax should be context sensitive; I don't want to see anything
> where we're explicitly html escaping, url encoding, etc... the syntax
> should understand whether it's in a html context, an attribute, a href,
> class, even a inline url(). ie: The syntax and markup must mingle
> together and be dependent on each other.
> - The syntax must support calling back to the host rather than requiring
> all the data pre-generated up front. Being able to call back is an
> absolutely necessity for the i18n system, and it's also necessary
> because I intend to have things like other forms of navigation than the
> sidebar, and we wouldn't want to pre-parse every single one of those
> when a skin will typically only use one. (This precludes XSLT without
> even needing to debate whether the language is powerful or clean to use.)
> I've already looked over all the existing template languages I could
> find and found none satisfactory. So in essence what I'm asking here is
> NOT for people to look for a template library to use, but for ideas on
> the best template language syntax we can implement for our purposes.
> XSLT is already out. And our parser is so complex we would never want to
> run it on each page, the syntax is also excessive for these purposes,
> and it can't be analyzed easily either so the suggestion to use WikiText
> for the template syntax is out too before anyone suggests it.
> This is the template language I've been thinking of for awhile:
> It fulfills the requirements, though it could use some small tweaks, eg:
> I might want to rethink the mw:header, mw:content, and mw:icon which
> aren't first-level things.
> But my biggest problem with it, is I never included a plan on how to let
> you do things like omit the login/logout/createaccount links from
> personal_tools and instead make them button-styled links located elsewhere.
> The best idea I could come up with was to include the functionality of
> WikiScripts/Lua/JS or whatever the language that we decide to include
> into our WikiText templates to deal with Tim's regrets on creating
> parser functions.
> So, I'd love to see other peoples ideas on the best syntax for our skin
> Or ideas or comments on how to fix the problem with the syntax I came up
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
> Wikitech-l mailing list
> Wikitech-l [at] lists
Wikitech-l mailing list
Wikitech-l [at] lists