<input type='submit' name="go" class="searchButton"
id="searchGoButton"
value="<?php $this->msg('searcharticle') ?>"<?php echo
$this->skin->tooltipAndAccesskey( 'search-go' ); ?> />
One thing our skin system "does" have is an extensive linker and system
for building tooltips and accesskeys for things using our i18n system.
And calls to the message system from skins are all over the place:
tagline, jumpto, and basically every header that's part of a skin itself
is all generated by calls to the i18n system, they are not hardcoded in
SkinTemplate.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
Fair enough, but when I've pushed for using PHP as
a template language,
even with a clever wrapper that would make injected data escaped by
default (so unescaping was obvious and could be more easily scrutinized
for XSS) I have been met with about equal resistance.
The state of things is that unless you are generating HTML 100%
procedurally (such as by using the Xml and Html classes) then you are
seen as doing something wrong. Adding something like smarty to the
system seems silly when we have two completely reasonable alternatives
at our disposal already.
XSL allows data to be injected without escaping:
<xsl:value-of select="." disable-output-escaping="yes" />
This is good because it's escaped by default, and any use of this
attribute would be obvious and could thus be scrutinized for XSS.
As for hooking in an i18n system, I'm not so sure skins should really be
arbitrarily injecting messages anyways. What's the use case here?
Generating tooltips? I'm a bit lost there.
- Trevor
On 12/6/10 8:13 AM, Daniel Friesen wrote:
> PHP -> XSL doesn't quite feel like much of an improvement in terms of
> cutting down on the verbose redundant code boilerplate required to
> insert something.
> ie:<xsl:value-of select="title"/> doesn't look much better
than<?php
> $this->text("title") ?>, as opposed to {$title|escape:html}.
> And I'm not sure how XSL handles html vs. text, we have stuff you want
> to htmlescape and stuff you want to output raw.
> Using an XSL lib also doesn't play nicely with things like calling a
> function to generate tooltips or fetch something from the i18n system.
>
> Unfortunately I think any designer we can convince to build a MediaWiki
> skin will probably dislike using XSL as a template language more than
> using PHP as a template language.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
>
>
> On 10-12-06 07:57 AM, Trevor Parscal wrote:
>
>> Have you considered using something like say XSL? If a skin was a
>> combination of a set of CSS/JS/image files plus an XSL file which took
>> XML data (which would be the page content and various user interface
>> elements) then you could avoid using a whole new template system. PHP 5
>> has an XSL 1.0 library compiled by default, and since it's implemented
>> in C, I would bet it's far more performant than any PHP implementation
>> of a template system aside from using PHP itself as a template system.
>>
>> Then again, there's a lot of people out there that dislike XSL for all
>> sorts of reasons - which to me have always carried the ring of
>> prejudice. I personally think XSL is awesome, and would defend it with
>> vigor.
>>
>> In any case, I'm excited about the work you are doing.
>>
>> - Trevor
>>
>> On 12/3/10 5:49 PM, Daniel Friesen wrote:
>>
>>
>>> Perhaps I should commit what I have so far even though it's not quite
>>> ready for use yet.
>>>
>>> It's enough to do this so far:
>>>
http://testwiki.new.wiki-tools.com/index.php?title=Main_Page&useskin=te…
>>> ((this runs off that ported monobook template I put in the pastie))
>>>
>>> Right now I'm using smarty's eval: which I don't want to use
because it
>>> re-compiles the template each time you run it.
>>> I really wanted to make use of MediaWiki's caching system because MW
>>> already has such a good caching system it's built in, and having to
>>> require extra permissions just to make smarty happy felt messed up.
>>>
>>>
>>> I have a bad habit of starting projects for fun and experimenting them,
>>> then abandoning them later. The ones I finish are usually the ones with
>>> company backing, the really really simple ones, or ones with some other
>>> sort of backing or other people working on it to. So having someone else
>>> working on it too would probably be motivating.
>>> This came after experimenting with porting Wikia's Monaco skin (got 1/3
>>> the way through), and after it I even started experimenting with writing
>>> an entire language embedded in php that could be used in MW. And there's
>>> my long lived vm based wiki farm experiment.
>>>
>>>
>>> One possibility I suppose, would be to use the vector array as the
>>> standard, but hardcode monobook to flatten it and relocate the tagline.
>>>
>>> Some ideas for the templates besides fixing caching... We should
>>> consider a method of doing personal_urls and whatnot using some blocks
>>> or functions that can aide in the generation of the links and make them
>>> simpler to build with tooltips and whatnot. Perhaps also some sort of
>>> block for content to automatically place the dataAfterContent. The
>>> sidebar block could be made better potentially.
>>> Besides footer_links we could also consider moving most of the toolbox
>>> out of monobook and whatnot. Converting it mostly into something you can
>>> loop through.
>>>
>>>
>>> Btw, the new powered by icon, using a little more rounded and fancy
>>> background:
>>>
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/images/…
>>> Anyone else think it feels slightly out of place in monobook?
>>>
http://en.wikipedia.org/wiki/?useskin=monobook
>>> I debated tweaking the poweredby, etc... buttons to instead use
>>> something a little more component style, where the content of the button
>>> is an image, but the bg is provided by the skin. Giving you the same
>>> style as before in monobook, but that nice new fancy style in vector.
>>>
>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
>>>
>>>
>>> On 10-12-03 11:10 AM, Trevor Parscal wrote:
>>>
>>>
>>>> This is a really awesome project, I'm sure we can figure out a way
for
>>>> Vector and Monobook to be able to use the same arrays.
>>>>
>>>> Let me know if you want some help.
>>>>
>>>> - Trevor