Супер скин

Pavel Astakhov

Гуру MediaWiki
Регистрация
06.05.2015
Сообщения
162
Реакции
84
Всем привет!
У меня есть идея создать скин для движка Медиавики, который можно будет модифицировать как обычную вики страницу.

Грубо говоря, сам скин будет абсолютно пустой, все графические элементы будут размещаться на специальной защищенной вики странице.

Каким образом можно разместить элемент "Меню пользователя" на этой специальной странице?
С помощью расширений PhpTags.

Что такое PhpTags? Это расширение, которое работает аналогично Magic words, т.е. вы пишете строки, которые содержат инструкции для расширения, оно их интерпретирует и выполняет заданные действия и может вернуть значение в виде строки или графического элемента (да и вообще чего угодно), например "Меню пользователя".

Чем PhpTags отличается от Magic words?
1) Используется PHP синтаксис. (Важно! очень похоже, что написанный PHP код будет выполняется непосредственно в среде PHP, но это не так. Расширение имеет собственный интерпретатор PHP и никогда не выполняет PhpTag скрипт непосредственно в среде PHP.Работа PhpTags изолированна от PHP точно также как работа Magic words изолирована от PHP).
2) PhpTags работает очень быстро (а также позволяет передавать результат работы одной функции в другую без потери формата данных и производительности)

Как это работает?
Допустим в качестве скина используется страница MediaWiki:MySkin, содержимое этой страницы будет примерно следующим:
PHP:
echo '<table><tr><td>[[MyLogo.png]]</td><td>', new UserMenu(), '</td></tr>';
echo '<tr><td>', new MainMenu(), '</td><td>', new WikiPage( $pageName ), '</td></tr>';
echo '<tr><td>', new GoogleAds(), '</td><td>', new UsedCategories(), '</td></tr></table>';

Профит? Вы имеете полный контроль над всеми элементами внутри и снаружи. Можете располагать элементы в произвольных местах и в любом порядке, а также управлять содержимым этих элементов.
Примеры:
* Как добавить элементы в главное меню:
PHP:
echo new MainMenu( array( 'Моё меню' => array('[[Моя страница]]', '[[Другая страница|еще...]]') ) );
* Как запретить доступ к странице:
PHP:
if ( $pageName == 'Моя страница' && $userName != 'sysop' ) {
    echo 'Доступ к этой странице закрыт';
} else {
   echo new WikiPage( $pageName );
}
Как вместо стандартного меню использовать другое меню:
PHP:
echo new MySuperPuperMegaCoolMenu(); //new MainMenu();
Таким образом можно изменять не только отдельные элементы, но и встраивать и управлять глобальными вещами вроде Foundation и Bootstrap со всеми вытекающими...

Как это выглядит в живую можно посмотреть на сайте test.foxway.org, на примере виджета Slick
Там же есть открытое для редактирования пространство имен Sandbox можете создать свои странички и поиграться...
Самого скина еще нет, это все только концепция.

Требуется несколько добровольцев (фокус группа) которые понимают о чем тут написано и желающих испытать эту технологию на себе. Нужно будет определить список необходимых элементов, их параметров и прочее. Затем испытать как все это работает и написать отзывы для улучшения продукта.

Сам PhpTags в первую очередь разрабатывался для использования на вики страницах и в шаблонах, но меня сейчас интересует именно использование данной технологии в качестве скина.
 
1.
В чем преимущество перед собственно скином? И там и там ПХП, только у вас еще и собственный интерпретатор ПХП, написанный скорее всего на ПХП - получается в любом случае нужно или знать ПХП или специалист.

2.
Что с кешированием? Поскольку у вас есть условия - как вы их думаете кешировать?

3.
Где будут стили и js?

4.
Как мне наиболее просто перенести скин с одного вики проекта на другой?
 
Мне нравится идея layout в chameleon, только я бы ее немного развил в чтонить подобное (синтаксис от балды, просто не требующий спец знаний сразу):

<html>
<head>
<title>{{PAGE:TITLE}} — {{SITE:TITLE}}</title>
{{SITE:Common.css}}
</head>
<body id="{{PAGE:TITLE}}">
{{PAGE:CONTENT}}
<hr />
{{page:categories}}
{{SITE:Common.js}}
</body>
</html>
 
1. В чем преимущество перед собственно скином?
Для того чтобы написать или изменить скин, нужны как минимум средние знания PHP и самое главное очень хорошие знания движка.
Как правило проблема заключается именно в последнем, особенно когда дело касается Скина, усугубляет отсутствие документации + частые изменения в движке.

Если использовать PhpTags, то нужны только минимальные знания PHP и HTML. Вот взять ваш пример выше "layout в chameleon" там требуется знать HTML + переменные типа {{PAGE:CONTENT}}, недостатки в этом решении:
1) логические операторы либо отсутствуют, либо очень ограничены
2) все переменные должны быть загружены заранее, независимо от того, используются они или нет, а это требует немалых ресурсов которые будут тратиться впустую.
Кстати Скины на PHP тоже страдают проблемой указанной в пункте 2. Базовый класс для Скина подготавливает кучу ненужной информации, которая используется не вся и не везде.

Так вот, PhpTags решает обе эти проблемы.
1) Вам доступна вся мощь и гибкость PHP
2) Загружаются (обрабатываются) только используемые ресурсы (переменные)

А по сути разница только в синтаксие, вместо {{PAGE:CONTENT}} нужно написать echo Page::CONTENT; (пример от того же балды) зато синтаксис PHP дает возможность писать echo Page::CONTENT, "\n\nКоличество символов в статье: ", strlen( Page::CONTENT );
При этом для "layout в chameleon" вам придется либо делать переменную {{PAGE:CONTENT_LENGHT}} и подсчитывать длину несмотря на то, что кроме 0,001% тех кто использует этот скин, это не нужно, либо не делать эту переменную. 99,9% хотелок пользователей: мне нужна вот эта штука, но только чуть по другому. Для тех кто может форкнуть и поддерживать расширение, это вначале не очень большая проблема, которая растет и становится большой, когда таких форков много и появляются изменения не совместимые с апстримом. Вот PhpTags как раз и решает эти проблемы.

PhpTags - это промежуточный слой, который позволяет использовать мощный синтаксис PHP и очень гибко управлять ресурсами. Да, интерпретатор PHP написан на PHP, по моим тестам он медленней нативного PHP в 10 - 350 раз, но он предназначен в первую очередь для эффективного управления ресурсами, а не для того, чтобы на нем писались программы. Хотя есть люди, которые пытаются кодить на нем шаблоны, и эти шаблоны работают быстро. Я для тестов брал шаблон с википедии для отрисовки карт. У них он написан на "сверхбыстром" LUA, я переписал на свой очень медленный PhpTags. В итоге мое решение на PhpTags оказалось быстрее в несколько раз, так как там нет накладных расходов.


2. Что с кешированием? Поскольку у вас есть условия - как вы их думаете кешировать?
Да, условия не будут кешироваться, точно также как Скин не кешируется. Кешируются только данные (кстати, в PhpTags есть возможность дать пользователю возможность управлять кешем) как и в обычном Скине. Просто часть логики передается под управление PhpTags.
Тут, если не злоупотреблять условиями и не писать 100500 строк кода, то PhpTags отработает очень быстро (практически незаметно) и при этом еще сэкономит часть ресурсов.

3. Где будут стили и js?
PhpTags будет содержать все используемые компоненты (меню, диалоги, иконки и пр.) пользователю нужно только расставить их по своему усмотрению и задать им желаемые параметры. При этом стили и скрипты которые необходимы для этих компонентов, это уже забота PhpTags.
Ну и никто не отменяет common.js и common.css.

Может я не так понял этот вопрос. Допустим пользователю нужна иконка фотоаппарата из FontAwesome. Он просто вставляет код:
PHP:
echo FA::camera_retro;
При этом все что нужно (скрипты и JS) PhpTags сам загружает. Если на странице не используется FontAwesome, то и ресурсы FontAwesome не загружаются.

4. Как мне наиболее просто перенести скин с одного вики проекта на другой?
Точно также, как перенести вики страницы с одного проекта на другой. (естественно на проекте должны быть установлены расширения PhpTags)
Плюс огромный бонус в том, что версия медиавики с огромной долей вероятности может быть любой, это как один и тот же код JAVA можно запустить на Windows, Linux и Mac. PhpTags выступает в такой же роли виртуальной среды и совместимость с разными версиями MediaWiki это его проблемы.
 
переменные типа {{PAGE:CONTENT}}
По сути, у хамелеона это теги, которые заменяются на код. Их можно как писать самому, так и использовать готовые, с параметрами и условиями.

логические операторы либо отсутствуют, либо очень ограничены
это да, но главные - зависимость от юзера и страницы присутствуют. И они кешируются.

Да, условия не будут кешироваться, точно также как Скин не кешируется
Кеширование нужно обязательно. Даже если ваш скин отрабатывает очень быстро, контент страницы может быть весь сложным (у меня есть страницы, которые генерируются по 5-10 секунд и живут только за счет кеширования). Для шаблонов с условиями нужно сохранять несколько версий кеша.



Хочу посмотреть на чтонить живое в виде исходника, на красоту, скрипты и стили пофиг, сугубо бэкенд.
 
По сути, у хамелеона это теги, которые заменяются на код. Их можно как писать самому, так и использовать готовые, с параметрами и условиями.
По сути, PhpTags делает тоже самое, но вы можете передавать произвольные параметры в произвольном виде и использовать произвольные комбинации этого всего. В общем ваши возможности с PhpTags ничем не ограничены благодаря синтаксису PHP. Суть PhpTags в использовании маленьких универсальных компонент, которые делают только одно дело, но делают его хорошо и могут свободно интегрироваться и взаимодействовать с другими компонентами. В общем это UNIX way, где вы можете взять вывод из одной программы, обработать в другой и передать результат в третью. Такой конструктор, в котором сейчас два кубика, но скоро их должно стать значительно больше. На данном этапе я просто хочу определить самые востребованные кубики.

Кеширование нужно обязательно.
Кеширование никуда не денется, я не понимаю в чем тут вопрос.
Вики страница будет использоваться исключительно для храниния PhpTags кода и его истории.
Скин будет брать код из этой страницы, обрабатывать его и выдавать результат.
Кеширование контента страницы это вообще головная боль вики движка, Скин туда не вмешивается (хотя может).

Хочу посмотреть на чтонить живое в виде исходника, на красоту, скрипты и стили пофиг, сугубо бэкенд.
Я же писал, что посмотреть можно на test.foxway.org. Там всего три бэкенд компонента FontAwesome, Slick и Vega, но это должно дать представление о том, как оно работает. там же можно и поиграться в пространстве имен Sandbox. Самого скина еще нету, но проблема собственно не в нем, а в компонентах PhpTags, которые нужны чтобы его собрать.

Вот примеры того, как это используют люди, причем используют самым не эффективным способом, но оно при этом работает:
http://kol.coldfront.net/thekolwiki/index.php/Template:StrangeCubeTable
http://kol.coldfront.net/thekolwiki/index.php/A_Volcanic_Cave

Вот тут написали несколько строчек кода в шаблоне, вместо того чтобы делать отдельное расширение для такой ерунды.
http://kol.coldfront.net/thekolwiki/index.php/Template:Roman

Здесь человек пишет кучу кода в шаблонах, и тоже вроде все работает:
https://thecasswiki.net/index.php?title=Special:AllPages&from=&to=&namespace=502

Вики с низким трафиком имеют возможность (пусть и может быть немного в ущерб производительности, хотя это спорный вопрос) легко делать те вещи которые им нужны. Вики с высоким трафиком могут использовать этот инструмент очень эффективно и решить целый ряд проблем, которые обычно сопровождают подобные проекты. Например как обновить движок, когда используется 100500+ расширений и часть не работает в новой версии, а часть требует последнюю версию движка. Или они просто ломают друг друга. Вот сегодняшний пример - человек использует расширения DPL и math, а когда они используются на одной странице DPL ломает math. И вот что ему делать в этой ситуации?
 
ПХПТег я оценил и понял, я хотел бы файл скина посмотреть и потрогать.
 
Я писал, что самого скина еще нет. Особых проблем сделать его не вижу, есть несколько возможных решений.
Самый очевидный - это просто брать текст со страницы скина и парсить его каждый раз.
Для не очень сильно нагруженных вики, коих подавляющее большинство, вполне себе вариант. Там не должно быть супер сложной разметки и кучи операторов. Это займет несколько миллисекунд процессорного времени. Ну хорошо, пусть неопытный пользователь сделает перегруженный скин, и скажем парсинг будет занимать порядка 50 мс. думаю это вполне приемлемо даже в таком виде.

Продвинутым можно дать возможность использовать raw html (скажем оператор Skin::eek:utput( $html ) ), тут будет практически без потерь производительности.

Как немного освобожусь, сделаю его, чтобы было что пощупать.
 
в пхптег можно юзать родные классы вики?
Можно юзать все что угодно, но только не на прямую а через соответствующий класс в PhpTags, который должен проверять данные переданные пользователем и управлять тем, что позволено делать пользователям, а что нет. Такой своеобразный класс-файрвол.
 
ПХПТег я оценил и понял, я хотел бы файл скина посмотреть и потрогать.
Нашел исходники своих экспериментов, делал ровно год назад и уже подзабыл что там да как.
Вроде как берется страница MediaWiki:SkinEmpty и просто парсится, как я уже описывал выше.
Результат можно увидеть задав параметр useskin=Empty
Там выдаются почти все элементы, которые должны выдаваться скином, единственное отсутствуют стили (но они сейчас не важны и на производительность никак не влияют) и менюшки (которые будут написаны на чистом PHP)
Исходники скина на gerrit.wikimedia.org.

Монитор сети на Firefox говорит, что время ожидания ответа от сервера при использовании скина Vector и Empty примерно одинаковое ( у Empty немного меньше, но не существенно). Также замеры скина Empty говорят, что на парсинг скина уходит 0.012 - 0.018 секунды. (там же время на инициализацию самого PhpTags, которое занимает обычно около 0.008 секунды)
 
Я нашел несколько проектов для обкатки данной технологии, тему можно закрыть.
Но если вдруг у кого-то возникнут вопросы по данной теме - пишите.
 
Назад
Верх