Последнее обновление:
О методологии разработки визуальных редакторов html
Редактор html-кода – это программа, позволяющая осуществлять его создание, исправление (редактирование). Простейшим из них является обычной блокнот Windows (Notepad). Более серьезным и функциональным является широко известный Notepad++. Конечно, существуют и еще более совершенные программы, например, та же WebStorm, которая уже, пожалуй, относится к IDE.
Известны также и другие, многочисленные редакторы html. По нашим оценкам, только основных их разновидностей их существует не менее 50…100. В этой связи можно отметить такие программы, например, Alaborn iStyle, Coffee Cup HTML Editor, DFM2HTML, HTMLPad и многие, многие другие [Редакторы html // http://htmleditors.ru/list_programm.html.]
Однако, в подавляющем большинстве своем, это – именно редакторы html-кода (с возможностью редактирования кода, в частности, на РНР и/или javascript). Конечно, при помощи таких редакторов, в принципе, вполне возможно создавать html-код. Однако, это, как минимум, сопряжено с некоторыми трудностями. Дело в том, что многие из них не позволяют посмотреть, как выглядит сформированный html-код в браузере, т.е. при открытии в нем соответствующей страницы.
Правда, есть довольно узкая группа редакторов, которые относятся к типу WYSWIG. Это, так называемые, визуальные редакторы, которые позволяют, в процессе редактирования, непосредственно видеть результаты, т.е. как будет выглядеть страница при ее открытии в браузере.
Однако, если рассмотреть, на самом деле, настоящих WYSWIG редакторов достаточно мало. Многие из них, которые именуются при помощи приведенного термина, на самом деле, таковыми не являются. К их числу, например, можно отнести Microsoft Expression Web, а также ряд многих других.
Существуют встроенные редакторы в так называемых «движках» (WordPress, Joomla!, Drupal, Битрикс и др.), но их нельзя назвать в полном смысле визуальными, ибо они, по сути, позволяют редактировать текст контента страницы сайта не непосредственно в том окружении, в котором он находится, в отдельном окне редактирования, что, конечно же, неудобно.
Фактически, WYSWIG редакторами в полном смысле этого слова (но, с определенным приближением) являются программы NVU, AdobeDreamWeaver. И, из известных программ, пожалуй, все… На самом деле, это не пустые слова: наш, достаточно богатый, опыт использования (тестирования) более, чем 30 подобных, наиболее известных и распространенных, программ позволяет уверенно сделать такой вывод. На самом деле, в настоящее время, как это ни парадоксально, НЕТ хорошего визуального редактора html, за исключением, быть может, AdobeDreamWeaver.
Однако, эта программа полна недостатков. Во-первых, в настоящее время ее использование возможно лишь на основе временной лицензии (помесячной, достаточно недешевой). Т.е. пользователь, используя ее, вынужден, как минимум, иметь постоянный доступ в интернет, что неудобно: ведь не всегда есть возможность работы онлайн.
Во-вторых, стоимость месячного абонемента, мягко говоря, немалая и составляет не менее 599 руб./мес. на дату написания статьи (31 мая 2016 г.) [Цены и планы подписки // https://creative.adobe.com/plans?single_app=dreamweaver&store_code=ru&promoid=KSPES (дата обращения: 31.05.2016).], что подходит, в основном, лишь профессионалам, постоянно занимающимся разработкой Web-страниц.
А ведь есть немало пользователей, которые делают сайты, как говорится, для себя. Кроме того, даже и Web-разработчики-профессионалы не всегда имеют большой объем заказов и/или не согласны уплачивать высокую арендную плату. Им не нужно работать в редакторе html постоянно. Но, при этом, их не устраивает качество так называемых «движков» (которые тормозят при передаче контента с сайта в браузеры пользователей, которые имеют уязвимости потому могут быть взломаны, которые, наконец, создают проблемы, если возникает необходимость сменить шаблон сайта).
На наш взгляд, уже тот факт, что программа (Adobe Dreamweaver) распространяется по временному абонементу и требует постоянного подключения к сети интернет является аргументом в пользу того, чтобы НЕ пользоваться ею, вне зависимости от того, какие удобства и функциональность она сулит. Видимо, не следует использовать такое программное обеспечение, которое как бы «привязывает» к себе пользователя.
К тому же, эта программа требует достаточно высоких ресурсов компьютера: не менее 1 ГБ памяти жесткого диска.
Кроме того, она «не до конца дружит» с динамическими страницами (как и NVU, см. ниже).
Интерфейс этой программы достаточно запутанный, а система обучения – сложная. Есть и еще немало иных, серьезных недостатков. Но, важнейшим их них является тот, что она, несмотря на старания разработчиков, все-таки не до конца точно отображает контент сайта так, как он отображается в браузере.
Что же касается программы NVU, то это, без сомнения, действительно – WYSWIG редактор. Т.е. она, в соответствии с принципами WYSWIG, позволяет редактировать и/или создавать контент страницы, почти что непосредственно видя, как он будет выглядеть после открытия в браузере. Кроме того, она дает (правда, очень-очень слабую) возможность редактирования html-кода.
Однако, все дело как раз в этом «почти». Дело в том, что эта программа, к примеру, не умеет работать с динамической сборкой страницы по SSI-технологии, не говоря уже о РНР.
Т.е. если необходимо редактировать динамически созданную страницу, следует вначале получить ее код-html, вставить в соответствующее окно программы NVU и затем редактировать его. После окончания редактирования, конечно же, придется делить код на его динамические составляющие. Что, конечно, очень неудобно и долго, особенно, если идет речь о редактировании большой группы страниц. Кроме того, последняя версия этой программы вышла… в 2006 г. Разработчик ее, Глазман, выразился, что целесообразно бы ее полностью переписать и после чего вообще прекратил разработку.
Конечно, есть выполненный по аналогии с нею браузер SeaMonkey (несколько упрощенная версия NVU, уже российской разработки), который позволяет делать редактирование открытой страницы прямо в окне этого браузера. Но, опять-таки, если страница является динамической, то придется потом разделять ее на отдельные компоненты (части), из которых она собирается «на лету» сервером. Кроме того, функциональность этого браузера для целей создания и корректировки страниц html оставляет желать лучшего.
Таким образом, после небольшого обзора можно сделать однозначные выводы:
1) В настоящее время (2016 г.) отсутствует хороший, целесообразный для применения, визуальный редактор, при помощи которого можно было бы редактировать не только статические, но и динамические (например, собранные по технологии SSI или с применением РНР) страницы;
2) Большинство программ, именуемые WYSWIG редакторами (т.е. визуальными) таковыми, на самом деле, не являются.
3) Имеется потребность в WYSWIG редакторе.
Следовательно, существует необходимость в разработке WYSWIG редактора.
Для этого целесообразно определить требования, которым он должен удовлетворять. Если рассмотреть различные публикации, мнения программистов и пользователей, то, на самом деле, картина вырисовывается довольно противоречивая. Ибо, вплоть до настоящего времени, строгих стандартов на WYSWIG редакторы, по сути, нет.
Что же собой представляет визуальный редактор? Сформулируем такое определение: это такая программа, которая позволяет редактировать (исходный) html-код страницы сайта как при помощи исправления html-тегов, так и непосредственно на странице сайта, открытой в браузере. При этом результаты редактирования должны отображаться одновременно как в исходном коде, так и на открытой странице.
Для того, чтобы видеть, как будет выглядеть страница сайта, открытая в браузере, WYSWIG редактор должен, по сути, представлять собой… браузер. Да, именно так. Визуальный редактор (WYSWIG) должен обладать всеми теми возможностями браузера, которые последний имеет для целей отображения контента страницы.
В самом деле, зададимся вопросом – что же представляет из себя современный браузер? На самом деле, это – весьма сложная программа, по мнению ряда исследователей и разработчиков, представляющая собой подвид операционной системы. С чем вполне можно согласиться.
Ведь браузер должен корректно отображать контент открываемой страницы, поддерживая, как минимум, три технологии:
1) html,
2) CSS,
3) javascript.
Кроме того, как уже говорилось, есть еще технология SSI и др., о чем несколько отдельный разговор.
Если вспомнить, сколько имеется тегов, сколько у некоторых из них присутствует свойств… плюс еще – сколько возможностей javascript – ведь их тоже необходимо ВСЕ реализовать в браузере – то становится понятным, насколько это титаническая работа – сделать корректный, «правильный» браузер.
В свое время (конец 90-х – начало 2000-х годов) имела место так называемая «война браузеров» (нечто типа ненужной, впоследствии затихнувшей, конкуренции), когда каждый браузер отображал свойства CSS и команды javascript – по-своему, т.е. как хотели его разработчики и, зачастую, «в пику» другим браузерам. В итоге Веб-разработчики испытывали неудобства, пытаясь для каждого браузера писать свой, индивидуальный код для страницы сайта. Понятно, что это очень неудобно, да и ненужно.
В последнее время подобная «война» немного стихла, разве что, остался такой браузер, как Internet Explorer (как говорят веб-разработчики, особенный, в своем роде), который некоторые свойства отображает не так, как все остальные, наиболее известные, браузеры (Opera, Firefox, Safari, Google Chrome). И по этой причине под него приходится «подстраиваться», разрабатывая дополнительные команды и условия (особенно, если речь идет о более ранних версиях этого браузера, например, IE6…IE9). Здесь мы не будем на этом останавливаться – достаточно посмотреть имеющееся множество публикаций (в основном в сети интернет).
Кроме того, свою лепту в такое «разнообразие» в чем-то вносят, например, Android, iOS…
Если же говорить о менее известных браузерах (как принято выражаться, «альтернативных»), то у них, как правило, поддержка свойств CSS, html, – ниже; впрочем, большинство современных разработчиков вообще не принимает их во внимание при разработке страниц сайтов.
Таким образом, становится понятным, что написать WYSWIG редактор, что называется, «с нуля» - это задача достаточно сложно выполнимая. Вероятно, именно поэтому даже Adobe Dreamweaver в определенной степени некорректно транслирует некоторые свойства CSS, не говоря уже о javascript. Из-за этого страница, открытая в окне визуального просмотра, все-таки, вообще говоря, не совсем точно отображается (точнее, не совсем так, как рассчитывал ее разработчик).
Отсюда следует, что визуальный просмотр результатов WYSWIG редактора должен осуществляться в браузере.
Да, именно так. Ибо, еще раз: либо следует делать свой браузер (или его аналог), который будет являться, в той или иной мере, копией наиболее известного (пусть и основанного на лицензии GPL, которая дает возможность бесплатного использования, но, тем не менее). Либо – использовать уже имеющийся, т.е. основываться на его конкретных свойствах, особенностях интерпретации свойств html, CSS и команд javascript.
Исходя из этого, можно предложить две возможности отображения страницы в WYSWIG редакторе:
1) Редактирование страницы в редакторе html-кода с последующим ее просмотром в браузере;
2) Редактирование страницы в окне браузера.
Если говорить про первый вариант, то он, фактически, в той или иной мере, уже реализован в имеющихся на сегодняшний день неполноценных WYSWIG редакторах. Однако, как уже говорилось, это неудобно, особенно для динамических страниц. Неудобство заключается в том, что невозможно осуществлять исправление страницы непосредственно в окне браузера. Т.е приходится вначале осуществлять редактирование в коде html, а уж потом – просматривать результаты в окне браузера (после обновления страницы). Например, чтобы исправить орфографическую ошибку, ее вначале необходимо еще найти в html-коде (среди тегов и спецсимволов), исправить, сохранить файл, затем перейти в окно браузера, обновить страницу – и только после этого посмотреть, как она будет выглядеть после правки.
Насчет же второго варианта – можно сказать, наблюдается «отсутствие целесообразных возможностей» (за исключением уже упомянутых AdobeDreamWeaver, NVU).
Консорциум W3C не так давно предложил свойство contenteditable="true".
Это свойство можно включить в любой блок (div), а также в любой другой элемент (h, p, span, ul и т.д.).
Это свойство дает возможность редактирования контента, который содержится в соответствующем теге. Например, если объявить тег body редактируемым (т.е. назначить ему свойство contenteditable="true"), то появится возможность редактировать весь контент страницы html, открытой в браузере.
Итак, вполне возможен визуальный редактор, основанный на любом браузере (точнее, на том, который поддерживает указанное свойство; но это – практически любой современный браузер), благо это позволяет свойство contenteditable="true".
Однако, здесь возникает ряд проблем. Первая и, пожалуй, самая важная (хотя, кажущаяся, на первый взгляд, несущественной) – как сохранить результаты редактирования. Дело в том, что современные браузеры, как правило, не предназначены для создания WYSWIG редакторов (хотя консорциум W3C всячески рекомендует использовать свойство contenteditable="true" именно для этих целей; видимо, за этим свойством – будущее для html-редакторов).
Если же просто воспользоваться стандартной возможностью браузера «сохранить как», то будет сохранена ВСЯ страница. Это допустимо для статических страниц, однако, с динамическими страницами, по понятным причинам, возникнет неувязка. Ибо при этом необходимо сохранять разные части страницы в, вообще говоря, различных файлах (базах данных) или собираемой по технологии SSI.
Поэтому необходимо будет использовать соответствующий алгоритм разделения частей веб-страницы. Тем более, что некоторые их части может быть запрещено редактировать.
Здесь целесообразно применять соответствующие javascript – команды, которые позволяют копировать все содержание открытой в браузере html-страницы в (строковую) переменную, которую можно потом, впоследствии, передать при помощи средств РНР на сервер. Который, затем, вызывая перезагрузку страницы, передаст браузеру «новую» версию страницы (с уже сохраненными изменениями). Или же, используя технологию AJAX, можно передать данные с сервера без перезагрузки страницы.
Для редактирования контента в пределах абзаца (блока) целесообразно также использовать javascript, который обладает возможностями форматирования содержимого тегов посредством применения свойства document.getElementById("id").innerHTML. Например, чтобы задать для части текста (контента) определенный цвет, размер шрифта и т.п. – следует просто указать соответствующие свойства (style).
Таким образом, теоретически, имеются возможности для реализации полноценного WYSWIG-редактора, основанного непосредственно на браузере. Возникает лишь вопрос в дополнительной программной оболочке, которая будет давать пользователю возможность вносить требуемые исправления в контент страницы, а также сохранять результаты, выделяя динамические ее компоненты.
Такая программная оболочка может представлять собой или плагин к браузеру, или отдельную программу.
Если вести речь о плагине, то здесь возникают сложности, ибо он должен быть кроссбраузерным (причем, как минимум, отчасти, работающим на стороне клиента). Создать кроссбраузерный плагин – дело решаемое, но сложное. Поэтому видится гораздо более простым второй способ – в виде отдельной программы. Например, она может быть написана на языке javascript.
Этот язык позволяет вносить изменения в исходный код html-страницы, открытой в конкретный момент в браузере. Есть как минимум три замечательных особенности JavaScript:
- Полная интеграция с HTML/CSS,
- Простые вещи делаются просто,
- Поддерживается всеми распространёнными браузерами и включён по умолчанию.
Существуют, однако, ограничения JavaScript:
- JavaScript не может читать/записывать произвольные файлы на жесткий диск, копировать их или вызывать программы. Он не имеет прямого доступа к операционной системе.
Современные браузеры могут работать с файлами, но эта возможность ограничена специально выделенной директорией – «песочницей». Возможности по доступу к устройствам также прорабатываются в современных стандартах и частично доступны в некоторых браузерах. Правда, при помощи JavaScript можно открыть файл и считать его (при условии, что пользователь согласится на это; но, работа с файлами без согласия пользователя, в целях безопасности, невозможно).
- JavaScript, работающий в одной вкладке, не может общаться с другими вкладками и окнами, за исключением случая, когда он сам открыл это окно или несколько вкладок из одного источника (одинаковый домен, порт, протокол).
Есть способы это обойти, но они требуют специального кода на оба документа, которые находятся в разных вкладках или окнах. Без него, из соображений безопасности, зайти из одной вкладки в другую при помощи JavaScript нельзя.
- Из JavaScript можно легко посылать запросы на сервер, с которого пришла страница. Запрос на другой домен тоже возможен, но менее удобен, т. к. и здесь есть ограничения безопасности.
Однако, для того, чтобы сохранить результаты редактирования, необходимо будет использовать ту или иную серверную технологию, т.е. программу, реализованную на РНР, Perl, Java, С/С++ и т.д. Следовательно, WYSWIG-редактор может иметь технологию «клиент-сервер». Это означает, в частности, что для работы WYSWIG-редактора будет необходим сервер. Например, если редактирование html-файлов в режиме WYSWIG осуществляется на локальном компьютере, то, соответственно, потребуется хотя бы виртуальный сервер. Впрочем, это не является существенным недостатком данной технологии, ибо, во-первых, виртуальный сервер в любом случае потребуется ля качественной отладки html- страниц перед тем, как их копировать на сервер (хостинг).
Во-вторых, в настоящее время имеется ряд достаточно качественных, в том числе, и бесплатных программ-виртуальных серверов, например, Denwer.
Вместе с тем, есть еще возможность использования языка Java. Он интересен, в первую очередь тем, что подписанный Java-апплет, вставленный в html-код WYSWIG-редактора, может выполнять всё то же, что и обычная программа, установленная на компьютере посетителя (например, написанная на языке С). Конечно, для этого понадобится согласие пользователя при открытии такого апплета. Но, понятно, что пользователь WYSWIG-редактора может дать такое согласие. Правда, при этом (в том числе, при работе с вспомогательными файлами) пользователь должен будет каждый раз давать его, что может быть не совсем удобным.
Достоинства Java для целей использования в WYSWIG-редакторах:
- Java может делать всё от имени посетителя, совсем как установленная программа. Потенциально опасные действия требуют подписанного апплета и согласия пользователя.
Недостатки
- Java требует больше времени для загрузки,
- Среда выполнения Java, включая браузерный плагин, должна быть установлена на компьютере пользователя и включена,
- Java-апплет не интегрирован с HTML-страницей, а выполняется отдельно. Но он может вызывать функции JavaScript.
Среда выполнения Java является универсальной. Кроме того, она используется в настоящее время в ряде программных приложений, в той же WebStorm, например. Эта среда очень удобна тем, что, с одной стороны, она – кроссбраузерная, кроссплатформенная, что упрощает работу разработчика.
С другой стороны, эта среда и технологии, основанные на ней, могут быть, в некотором роде, заменой технологии «клиент-сервер», т.е. она необязательно требует наличия программы-сервера (если говорить о WYSWIG-редакторах).
Сказанное выше можно, для целей наглядности, отразить на рисунке:
Отметим, что, на самом деле, необходимость использования программы-сервера (в рамках первого варианта) является не слишком обременяющей. Дело в том, что мало-мальски серьезный сайт отлаживается и тестируется так или иначе – с его использованием – с целью реализации, что называется, реальной обстановки. Поэтому с этой точки зрения требование запуска WYSWIG-редактора в среде сервера не является недостатком первого подхода.
Что же касается функциональности, то здесь нельзя отдать предпочтение ни одному из подходов. Ибо, как уже говорилось, наличие среды Java позволяет не только свободно обращаться к файлам, но и запускать программные коды, написанные на других языках программирования. То же самое, впрочем, можно реализовать и средствами РНР или, к примеру, С/С++.
В отношении скорости работы WYSWIG-редактора можно сказать, что в рамках первого варианта имеется больше возможностей для более высокой быстроты работы (т.е. быстродействия). В частности, можно реализовать на высокоуровневой технологии РНР лишь небольшую (базовую) часть программы, все остальное выполним на С/С++. Тогда как при использовании второго варианта (на базе платформы Java) скорость работы будет лимитироваться быстродействием этой платформы.
Таким образом, выбор разработчика WYSWIG-редактора между двумя предложенными вариантами зависит от того, что именно для него является более критичным: быстродействие или возможность редактировать (в том числе, и динамические) html-страницы без использования программы-сервера.
На наш взгляд, в связи со всем вышесказанным, более целесообразным является первый вариант (основанный на технологии клиент-сервер), как более быстродействующий.