Добрый день!
Наверное, с каждым днем, все больше и больше разработчиков тем дизайнов, плагинов и приложений (в том числе и запросы в Webasyst) начали сталкиваться с проблемой совсместимости всех установленных плагинов, тем дизайнов и приложений и работы их вместе на одном проекте. Ведь по сути единого стандарта для подключения JS библиотек нет, подключай чего хочешь и сколько хочешь, не взирая на то, что в проекте уже может быть использована эта библиотека.
При модерации одного плагина все это будет корректно работать, но ведь когда плагинов стоит 10-20 и все они выводятся во frontend, получает куча ошибок из-за подгрузки по 3-5 раз одной и той же библиотеки. Как пример библиотека JQuery UI и пр.
Не планируется ли изменения в способах подключения и изменения стандарта для подключения сторонних библиотек? Например как на сайте http://jsfiddle.net/ где можно просто объявить об использовании того или иной библиотеки фреймворк сам её подключить при необходимости.
хорошая идея.
+
Надо было в "идеи и предложения" публиковать.
А разве разработчики плагинов не смотрят, что у них подключено, до запуска их творений ? (o_O)
ИМХО в jsfiddle.net реализован механизм подключения сторонних библиотек для отладки кода + возможность поделиться кодом при поиске ошибки. Так зачем такой функционал конечному потребителю? Вместо рабочего продукта, получим сайт с кучей всплывающих ошибок и системных предупреждений.
Александр, вы видимо плохо прочитали текст топика. Речь о том, что разные разработчики используют одну и туже библиотеку и как следствие два этих плагина потом не будут вместе работать из-за подгрузки этой библиотеки несколько раз.
Почему не будут работать? это может быть из-за разных версий библ, но и то вряд-ли — второй раз, скорее всего, не загрузится просто библа и все. плагин, рассчитанный на более познюю версию может не заработать. В общем, сплошные "может".
Есть способ прежде чем грузить библиотеку проверять, а не загружена ли она уже...
И некоторые хорошие разработчики давно такую практику применяют и никаких проблем не возникает.
А проблему плохих разработчиков, которые ни о чём, кроме как о своём плагине/теме не думают, решить довольно сложно...
Ваша идея обречена на провал, т.к. вот возьмём тот же bootstrap, в теме может быть подключён не полный, а частичный, а плагину нужна та часть которой в теме нет.
И как же вы представляете общий механизм подключения js?
В теме описывать все куски bootstrap, которые входят в тот js-файл, который в теме есть?
Кто из разработчиков тем это будет делать? Я уверен, что никто, потому что часть из них даже не поймёт что от них хотят.
Всё это лишние усложнения как для разработчиков тем, так и для разработчиков плагинов.
Вот поэтому и нужно что-то сделать с темами, чтобы они обзавелись какими-то своими обработчиками, раз в них нельзя выполнять код.
Или сделать тысячу хуков в разных местах темы, чтобы из плагинов можно было туда что-то дописать.
Страшное дело интегрировать куски кода сторонних разработчиков в тему и потом боятся обновиться на новую версию установленной темы. Да и сами разработчики тем почему-то вынуждены беспокоится о других плагинах, вместо того, чтобы сосредоточится на улучшение своей темы.
Последний апдейт "удобная покупка" - содержал в себе кучу заготовок для плагинов, а ведь ребята могли сделать что-то новое в своей теме вместо ковыряние других плагинов.
У даталайфа сейчас такая же система с шаблонами, сходи туда, скопируй это, замени там, удали то. Сделать это не проблема, но через пару месяцев успешно забывается где и что правилось, а после обновления хватаешься за голову и думаешь как вернуть все что было сделано.
Про бекапы не надо говорить, кто их делает - тот молодец. Но люди разные бывают, ситуации тоже.
И раз уж зашла речь о разработчиков плагинов, то давайте на чистоту - некоторые плагины написаны как-будто школьниками. О качестве кода речи не идет. И на вас, как на модераторах магазина приложений должна лежать ответственность по модерации
всякого говнаплагинов с низким уровнем кода (раз уж вы признали, что есть авторы которые не заботятся о проверках на подключение js и вы это видите).От этого выиграют все:
Я очень большой фанат, вашего движка, поэтому надеюсь, что вы хотя бы частично прислушаетесь :)
хуков вполне достаточно. Тысяча хуков → дольше генерация страницы.
Это заморочки удобной покупки. Теперь приходится тратить время на выбрасывание кучи ненужных заготовок и настроек. :)
полезная вещь — VCS.
Насчет кода — обещали в скором будующем какие-то изменения на эту тему в аппсторе.
Не будут. Практика показала, что многие даже не могут прочитать наши требования по размещения в магазине и наступают на одни и те же грабли каждый раз. Еще большая часть разработчиков не в состоянии перед отправкой на публикацию взять и проверить установку плагина на чистой установке с нашими рекомендациями.
А отказывать навсегда по причине: ваш плагин полная фигня и реализован криво довольно проблематично, т.к. это всё же субъективно.
Поэтому мы и вводим в магазине вебасист и в модерации те изменения, о которых недавно писали в блоге.
Что касается тем и плагинов, то боюсь это неразрешимая в общем случае задача.
Плагин хочет вывести HTML, в разных темах этот HTML будет выглядеть по разному и в разных местах (там где решил разработчик темы), потому что стили у всех свои.
В итоге приходится либо делать поддержку темы в плагине, либо в теме подержку плагина, либо вносить какие-то правки в тему дизайна.
Хорошая практика: в теме дизайна оставлять пустой файл user.css для пользовательских стилей, чтобы основные файлы стилей не нужно было трогать и не иметь проблем с обновлением темы.
Немного пятничного флуда нагню. На самом деле нет ничего невозможного.
Я преследовал в свое время несколько иную цель — собрать подключение и инициализацию всех js внутрь body (в начало или в конец, неважно, уже лет 5 как неважно, но многие любят перед закрывающим body).
экспериментировал года полтора назад, были какие-то нестыковки связанные с вложенностью шаблонов. но, думаю, решаемо это все.
Я в классе view менял код addJs чтоб оно вело учет подключенных скриптов. причем для распространенных можно было просто написать addJs('jquery') и все. И это был ассоциативный массив вида "библа"=>"путь_к_библе"
И еще отдельно можно было блоки кода таким-же образом вставить типа addJsBlock($js_code)
В хуки передавалась также ссылка на $view, чтобы плагины в обработчике хука могли прицепить что-то свое
В шаблоне хелпером сначала все js() выводились, потом блоки js, обернутые все вместе в $(function(){ /* тут все js блоки*/ });
Это типа концепт и он недоработанный :)
Что касается изготовителей шаблонов. Они 99% вероятностью пихают туда полностью весь бутстрап и все остальное. Просто чтоб не возникало вопросов при доработке клиентом. И классы бутстраповские оставляют в покое — как глянешь внутрь, там row-fluid да col-sm-*. В универсальных шаблонах для массового применения нет смысла сильно кастомизировать, потом с поддержкой намучаешься.
"Хоть идея хороша, но не наша анаша" (с)
Провальная идея такая на корню -99%
В плагинах просто проверять подключение библиотек и все. Как вариант моедраторам резать плагины без проверки