On 11-03-13 08:20 AM, Marcin Cieslak wrote:
Daniel Friesen<lists(a)nadir-seen-fire.com>
wrote:
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout
I have some plans for a new way of laying out skins in a new skin system.
The key changes being; The creation of new region block handling in the
system (default skins typically just including a standard body region
and messages region) to replace newtalk, sitenotice, the jsmessage div,
bodytext, catlinks, and dataAfterContent (used by flaggedrevs, smw, and
other extensions). And changes to what types of navigation we support
and how dominant the location of the toolbox is.
This new layout and system will likely be done using a planned xml/html
based template syntax.
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_template
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system#xml.2Fhtml_templ…
Did you see Zope Page Templates
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx
There is even a PHP implementation out there (TAL).
It's a consistent and mature system (I still prefer
tagsoup-like templating, but that has obvious disadvantages).
I did look over TAL.
However the data template based nature of TAL would
likely result in the ugly use of __get and friends to achieve the same
efficiency of not loading pieces we won't use in a skin. And I do
believe TAL's syntax is much harder for non-tal users to pick up right
away than the syntax I'm looking at. And now that I think about it, I
have a feeling TAL is incompatible with most of those advantages of the
xml syntax, I probably couldn't apply them and we'd be back in the same
spot.
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Skin_examination
I would also like to eventually eliminate our three skins using the
legacy system (Nostalgia, Standard/Classic, Cologne Blue). They don't
"properly" use our SkinTemplate system and require another 930+ lines of
code dedicated to their support, full of code duplication which
repeatedly gets in the way of new features because we insist that any
change we make to the ui should be backported to also work with legacy code.
That
depends whether you want to change people or the system. I happened
to survive a whole Monobook era on either Standard, Simple and finally
settled down on Nostalgia due to its unique feature of having dropdown
list of specialpages (I use [[Special:Specialpages]] a lot). Then
switched to Vector with some reluctance, but finally accepted it.
If you plan to have a new, pretty and universal templating system
for the skins, please do try to accommodate those as a challenge.
It is also worth looking at some non-MediaWiki supplied skins,
like one of my almost favourites Beagle
(
http://beagle-project.org/skins/beagle-skin.tar.gz, that one
builds on QuickTemplate/Monobook I think) but you
fill find many others. It could be interesting to see those
that depart from the typical MediaWiki look (you know,
that thing that makes you type "Special:RecentChanges" in the
URL bar :)
Not to mention the ever-recurrng subject of the mobile site :)
//Marcin
Structurally nearly every QT/MB based skin I see is not really any
different from being MonoBook from the pov of skin engine development,
they're really already catered to because that's pretty much the only
kind of skin that our current skin system is designed to facilitate. I
"am" looking at supporting drastically different structures of skins,
eg: the kind you see on
baseswiki.org ones with different types of
navigation that don't fit within the limited capability of our
MediaWiki:Sidebar obsessed navigation model. The kind of skin I bet
plenty of businesses trying to adapt MW and personalize it are dying to do.
I'm also trying to take into account: Wysiwyg style web builders made to
export cms skins and trying to ensure the skin system doesn't drift into
a region where they can export to other engines but MW is too
fundamentally odd they can't export to it effectively. The ability to
create skins without an extra blob of php code for each skin,
essentially the ability to create an extension that provides skins from
arbitrary sources like the database or on-wiki pages. And take into
account template languages and there php exec capabilities and attempt
to ensure it's possible to create a baseline majority of skins out of
pure-tpl in a way that wiki farms could allow users to upload entire
custom skins without fear of script injection vulnerabilities on the farm.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]