Forums / National / Russian / Модули и плагины / формы ответов для форума и комментариев

Неоправданно лишний код и тормоза - это плагин из 30 частей, реализующих одно и то же.

Мне это напоминает кое-что, с чем периодически сталкиваюсь со времен первого публичного проекта: нежелание менять привычки. Регулярно встречаю людей, выступающих категорически против JavaScript, CSS и т.д. где-либо, аргументируя это тем, что все это можно реализовать с помощью PHP и без всяких модных штучек. То же самое касается шаблонов, MVC, СУБД, чего угодно в принципе. Зачем придумывать новый костыль, если можно сделать по-старинке? Но стоит приобрести небольшой опыт, и консерватизм улетучивается.

Что я хочу сказать: Богу богово, Кесарю кесарево. Немного логики.

Формировать комплексную разметку в коде - это приемлемо только если такое понятие как "скин" или "тема" в проекте отсутствует напрочь. Формировать простую разметку в коде - это типичное решение для движков на CSS шаблонах. Но ни Seditio, ни Cotonti к ним не относится. В принципе, я не против CSS-шаблонов, особенно если в разметке выдержан принцип семантической верстки, а скинмейкер - гуру в CSS, но на практике это встречается очень редко. Так что вынести всю разметку из ядра и отдать весь контроль над HTML и стилями скинмейкеру - для Cotonti не такая уж блажь.

Но с другой стороны, если принять во внимание, что редактор - это не всегда textarea и не всегда с одним набором атрибутов, то можно прийти к тому, что формирование HTML кода будет переложено с плеч PHP-плагина на плечи JS-плагина, предварительно снабженного данными с сервера. Некрасиво?

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

Мне вот кажется, тут мы имеем попытку решения проблемы обходными путями, потому как проблема заключается не в том, что должен выводить плагин, а в том, как его стандартно подключать.

Если бы был универсальный хук editor, реализующий необходимое взаимодействие между плагином редактора и целевым шаблоном, всего этого спора вообще не было бы. А вот каким образом организовать такой хук, учитывая сотню мелочей - это другой вопрос.

Совершенно согласен, что нехорошо markitup подключается в шапке, но это наименьшее зло, которое я мог сделать. Делать по куску плагина на каждую вставку - это расточительно, это меня раздражало в textboxer и раздражает в fckeditor. Когда я говорю о хуке, я говорю о исполнении целевого кода в текущем окружении и возврате его вывода в шаблон, а не о переписывании стандартного тэга. То есть редактор надо вызывать там где он нужен, а не ждать, пока он сам всавится туда, где у него получится. Примитивно это можно выразить так:
О конкретной реализации editor_display() я не говорю, это может быть и нечто другое. Я хотел бы об этом говорить, когда мы доберемся до изменений в системе плагинов (мультихуки и т.п.) и, возможно, инклюды будут заменены на обратные вызовы. Но сейчас рано об этом говорить.