Comments 28
piumosso разработал нечто схожее (http://futurecolors.ru/belonika/), можете пообщаться на счёт логики и производительности.
Думаю здесь будет полезна прямая ссылка на демо — azexo.com/azexo_composer/
итоговый исходник на JS имеет красивую и компактную ООП архитектуру
После этого я был слегка удивлен увидев исходники по 6к строк.
Редактор интересный. Интерфейс страшноватый (видно, что программист делал), но разобраться можно.
Особенно пугают вот такие штуки:
Являюсь автором похожего редактора, но немного другой направленности, поэтому примерно представляю, с какими трудностями пришлось столкнуться.
Обратил внимание на относительно небольшое потребление памяти, и отсутствие каких то явных утечек — вы явно над этим работали :)
Если удалить все секции на странице, то при попытке добавить Circle Timer будет ошибка «Uncaught TypeError: Cannot read property 'getContext' of null» в файле jquery.circliful.min.js, что не очень приятно.
Возможно, это случается, если я пытаюсь добавить виджет там, где можно добавлять только секции.
Еще вот ошибка: «Uncaught TypeError: Cannot read property 'children' of undefined» в azexo_composer.min.js:472, не понятно когда именно возникает, но тоже после того, как я все удалил на странице.
После удаления всего, что я сумел удалить, у меня все равно остались 2 контейнера, которые я не знаю, как удалить, а если нажать «Toggle editor», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
То, что редактор работает с работающими плагинами — очень круто, хотя и может быть затратно с точки зрения производительности.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Какие планы по дальнейшему развитию?
Особенно пугают вот такие штуки:
Являюсь автором похожего редактора, но немного другой направленности, поэтому примерно представляю, с какими трудностями пришлось столкнуться.
Обратил внимание на относительно небольшое потребление памяти, и отсутствие каких то явных утечек — вы явно над этим работали :)
Если удалить все секции на странице, то при попытке добавить Circle Timer будет ошибка «Uncaught TypeError: Cannot read property 'getContext' of null» в файле jquery.circliful.min.js, что не очень приятно.
Возможно, это случается, если я пытаюсь добавить виджет там, где можно добавлять только секции.
Еще вот ошибка: «Uncaught TypeError: Cannot read property 'children' of undefined» в azexo_composer.min.js:472, не понятно когда именно возникает, но тоже после того, как я все удалил на странице.
После удаления всего, что я сумел удалить, у меня все равно остались 2 контейнера, которые я не знаю, как удалить, а если нажать «Toggle editor», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
То, что редактор работает с работающими плагинами — очень круто, хотя и может быть затратно с точки зрения производительности.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Какие планы по дальнейшему развитию?
Особенно пугают вот такие штуки:
Вы очередной раз подвердили что мне надо срочно занятся этой проблемой. Ставлю высший приоритет в моем плане.
«Uncaught TypeError: Cannot read property 'getContext' of null» «Uncaught TypeError: Cannot read property 'children' of undefined»
Спасибо. Сейчас займусь.
После удаления всего, что я сумел удалить, у меня все равно остались 2 контейнера, которые я не знаю, как удалить, а если нажать «Toggle editor», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Демка доменстрирует немного не ту версию которая на github. Это демка редактора HTML шаблонов сайтов визиток — разработчик HTML шаблона указывает в какой части шаблона можно редактировать контент, вставляя туда контейнеры, пользователь редактирует/сохраняет и HTML файл обновляется на сервере. На счет исчезновения — после массы обновлений исходника периодически старое начинает не работать — раньше не исчезало — добавил в план.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
Вот эти тулбары контейнеров изначально и предназначались как корневой тулбар.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
Какие планы по дальнейшему развитию?
Держу в актуальном состоянии трело: trello.com/b/2oSG0c9U/azexo-composer
У вас какой проект если не секрет?
Я занимаюсь редактором platformalp.ru
Да, все же тут сложность в том, что и редактор и все плагины работают одновременно.
Как вариант, можно «перекрывать» все сеткой, которая визуально показывает, где что.
У меня кнопки секций видны всегда, виджетов — по наведению, а обводка у виджетов видна всегда, + разделители колонок всегда видны.
Благодаря этому можно быстро определить структуру страницы.
Обратил внимание, что у вас реализованы анимации с обширными настройками — отпала челюсть)
Внешность нужно подтянуть, потому что она мешает воспринимать серьезно весь функционал.
Для примера, вот есть такой редактор: plugnedit.com
Он достаточно функциональный, если с ним поработать немного, но дизайн портит все.
Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
Да, все же тут сложность в том, что и редактор и все плагины работают одновременно.
Как вариант, можно «перекрывать» все сеткой, которая визуально показывает, где что.
У меня кнопки секций видны всегда, виджетов — по наведению, а обводка у виджетов видна всегда, + разделители колонок всегда видны.
Благодаря этому можно быстро определить структуру страницы.
Обратил внимание, что у вас реализованы анимации с обширными настройками — отпала челюсть)
Внешность нужно подтянуть, потому что она мешает воспринимать серьезно весь функционал.
Для примера, вот есть такой редактор: plugnedit.com
Он достаточно функциональный, если с ним поработать немного, но дизайн портит все.
Спасибо за предложения.
Вообщето ваш проект очень близок к моему.
Я ставил целью делать редактор и для лендингов тоже.
Едиственное в чем различие, что я ставил еще цель делать редактор для специалистов тоже: дизайнеров, верстальщиков и программистов.
Я сейчас уберу нагромождение кнопок и скоро будет новая фича слайдер-презентация на основе Impress.JS (как обычно с визуальным редактором).
И может быть вас заинтересует мой проект :)
Стабильность поддержки можно оценить анализируя рынок codecanyon
codecanyon.net/user/azexo/portfolio
Вообщето ваш проект очень близок к моему.
Я ставил целью делать редактор и для лендингов тоже.
Едиственное в чем различие, что я ставил еще цель делать редактор для специалистов тоже: дизайнеров, верстальщиков и программистов.
Я сейчас уберу нагромождение кнопок и скоро будет новая фича слайдер-презентация на основе Impress.JS (как обычно с визуальным редактором).
И может быть вас заинтересует мой проект :)
Стабильность поддержки можно оценить анализируя рынок codecanyon
codecanyon.net/user/azexo/portfolio
А я сразу пошел по лендингам, и старался делать все для более простых пользователей. Не для верстальщиков и программистов, тогда все по другому, я думаю, выглядело бы.
Если говорить о других различиях, то вы виджеты рендерите один раз при инициации, и далее при каждом изменении настроек.
У меня виджеты и секции — шаблоны AngularJS, который при изменении настройки перерисовывает только ту часть шаблона, которая меняется в следствие изменения настройки.
Такой подход упрощает работу с шаблонами, но вот плагины интегрировать сложнее)
При изменении настройки мне нужно будет вызывать функцию интегрируемого плагина, которая произведет необходимые изменения в соответствии с изменением настройки. А если настроек много, то для каждой из них мне нужно будет делать подобные «нити», связывающие изменения настроек с функциями плагина, реализующими их.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
Если говорить о других различиях, то вы виджеты рендерите один раз при инициации, и далее при каждом изменении настроек.
У меня виджеты и секции — шаблоны AngularJS, который при изменении настройки перерисовывает только ту часть шаблона, которая меняется в следствие изменения настройки.
Такой подход упрощает работу с шаблонами, но вот плагины интегрировать сложнее)
При изменении настройки мне нужно будет вызывать функцию интегрируемого плагина, которая произведет необходимые изменения в соответствии с изменением настройки. А если настроек много, то для каждой из них мне нужно будет делать подобные «нити», связывающие изменения настроек с функциями плагина, реализующими их.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
У меня виджеты и секции — шаблоны AngularJS
Я детально анализировал исходники Visual Composer. В JS части там активно используется Backbone. То ли разработчик не владеет Backbone, то ли Backbone неудобный — но исходник разорванный с многочисленными перекрестными зависимостями — разбиратся в нем было трудно. Мне кажется одной из причин медленного развития этого проекта является неудачная архитектура — возможно изза слепой веры в могущество общепринятого фреимворка Backbone. Функционал который разработчик Visual Composer делал все эти годы (около 3х) я повторил за месяц (ну еще месяц на тестирование и багофиксы). Я решил вначале ключевую архитектуру сделать руками а потом если увижу выгоду добавлю Backbone (или Angular или чтото еще) — пока выгоду не увидел может быть проект слишком неизкоуровневый. Но как ни ругай архитектуру Visual Composer у него десятки тысяч продаж — все прощается — разработчик крут — с этим не поспоришь.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
можете увидеть их если откроете исходник страницы azexo.com/azexo_composer и подсветите строку «data-az».
Основным вариантом прорыва в этой проблеме вижу супер умный генератор JS загрузчика, чтобы он почти посимвольно строил исходник.
Но как подобратся к такой архитектуре — посмотреть на нее сверху — чтобы просто и компакто все звучало — пока не знаю.
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
Продвижением не занимался. Недавно только привел исходник в нормальный вид и исправил основную массу багов. Продвижением попробую еще позаниматся когда исправлю баги в моем таск/трекере. И хотелось бы чтобы вордпресную версию приняли на codecanyon — пока отказывают изза неуникальности набора фич — кстати это одна из причин почему в моем проекте туча фич — постоянно отказывают.
можете увидеть их если откроете исходник страницы azexo.com/azexo_composer и подсветите строку «data-az».
Ого!
Подозрительная, кстати, штука:
То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда?
Правильно я понял предназначение этих атрибутов?
Подозрительная, кстати, штука:
В этой демке много осталось не нужных атрибутов изза того что старые версии небрежно их плодили. Кстати может быть и текущая версия не все поддирает ненужное. Это все легко поправить — поэтому я поставил не высокий приоритет этому.
То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда? Правильно я понял предназначение этих атрибутов?
Да. Для 2х задач:
— для запуска JS виджетов во фронтенде.
— для их редактирования в режиме редактирования
Понял. Вот в data-атрибутах для запуска виджетов во фронтенде я вообще ничего плохого не вижу, и даже считаю это правильным. Сам так делаю.
Вот на счет редактора — да, тут не очень красиво.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Это не исправит проблему, но сделает ее менее страшной.
Возможно, сам подход — хранить данные в HTML не совсем правильный.
Получается, что смешивается модель с видом.
Что, если для последующего открытия страницы в редакторе экспортировать страницу в JSON, а при открытии — импортировать из JSON?
Так у вас будет больше возможностей по работе с версиями виджетов.
Я, например, в JSON сохраняю и версии виджетов, а при импорте, если есть более новая версия виджета, выполняю простую миграцию, которая приводит старый формат данных виджета к новому, например, добавляет поля, удаляет, переименовывает и т.д.
Вот на счет редактора — да, тут не очень красиво.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Это не исправит проблему, но сделает ее менее страшной.
Возможно, сам подход — хранить данные в HTML не совсем правильный.
Получается, что смешивается модель с видом.
Что, если для последующего открытия страницы в редакторе экспортировать страницу в JSON, а при открытии — импортировать из JSON?
Так у вас будет больше возможностей по работе с версиями виджетов.
Я, например, в JSON сохраняю и версии виджетов, а при импорте, если есть более новая версия виджета, выполняю простую миграцию, которая приводит старый формат данных виджета к новому, например, добавляет поля, удаляет, переименовывает и т.д.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Тут надо разделить:
1) есть data-атрибуты которые описывают структуру модели — которая нужна во фронтенде некоторым виджетам для активации. CMS и тотже Visual Composer добавляет невостребованные классы по которым по сути можно востановить модель документа — т.е. это частое явление на сайтах.
2) а есть data-атрибуты которые нужны были для рендерига HTML и по сути несут дублирующуюся информацию во фронтенде, просто в более формальном виде. они понадобятся только в режиме редактирования.
Осюда я думаю, что такой поход кажется некрасивым больше не изза того, что смешивается модель с видом а изза подобного дублирования информации и увеличения трафика. Даже если сохранить эти данные в JSON и положить кудато в одно место — это не избавит от настоящей неприятности. Как вариант можно сделать чтобы виджеты востанавливали эти параметры не из атрибутов а из имиже отрендереного HTML — это трудности для программиста — временные затраты на не очень эффективный код — для каждого виджета свой парсер.
Получается, что смешивается модель с видом.
В общем я тоже чувствую что-то не так изза этого смешивания. Но конкретную проблему сформулировать не могу. Только проблема трафика, которую я написал выше, и вижу возможное решение ее не через выделение атрибутов в JSON.
Похоже чтобы JS билдеру избавится от этой проблемы надо больше заставить программиста программировать — а проблема то пару % от веса страницы.
еще я давно обдумываю вариант фильтрации data атрибутов для анонимуса — для решения проблемы трафика.
думаю буду фильтровать по признаку нужен ли он только для функции рендеринга виджета — придется создать такое поле у параметра.
думаю буду фильтровать по признаку нужен ли он только для функции рендеринга виджета — придется создать такое поле у параметра.
Хороший проект. Впечатляет. Работа проделана большая.
Пару замечаний
1. Иконка Клонировать неправильная. Должны быть две овечки или две бумажки, что ли.
Иконки копировать/вставить тоже есть же стандартные, зачем что-то другое — это же путает пользователя?
2. Всё так быстро работает, есть опасность «заредактироваться», а кнопки «Отмена» нет.
Надо бы добавить, барин. Очень этово не хватает мужикам!
3. Не нашёл локализации.
platformalp.ru/ заодно попробовал — очень понравился, главное отличие и плюс в том, что редактор не прикручен к тексту и страница не перезагружается.
Однако у этих редакторов разные цели, и сделать лучше Azexo composer трудно — там много кнопок управления, не только редактор.
Интегрирование кнопок управления в редактор повысит удобство, однако наверняка намертво привяжет к одному редактору;)
В общем и целом — проект интересный, надо бы «форкнуть».
Пару замечаний
1. Иконка Клонировать неправильная. Должны быть две овечки или две бумажки, что ли.
Иконки копировать/вставить тоже есть же стандартные, зачем что-то другое — это же путает пользователя?
2. Всё так быстро работает, есть опасность «заредактироваться», а кнопки «Отмена» нет.
Надо бы добавить, барин. Очень этово не хватает мужикам!
3. Не нашёл локализации.
platformalp.ru/ заодно попробовал — очень понравился, главное отличие и плюс в том, что редактор не прикручен к тексту и страница не перезагружается.
Однако у этих редакторов разные цели, и сделать лучше Azexo composer трудно — там много кнопок управления, не только редактор.
Интегрирование кнопок управления в редактор повысит удобство, однако наверняка намертво привяжет к одному редактору;)
В общем и целом — проект интересный, надо бы «форкнуть».
Локализация — там все готово для локализации просто в этой версии не доделано.
Ммм… Где?
Вы ж понимаете, у проекта с локализацией совсем другой уровень.
Я б подключился.
Да, забыл показать своё мини-поделие.
Тестовый шаблон с онлайн редактированием:
fromgomel.com/edit_skin_test/
Суть в том, что в стандартный 2-колоночный шаблон добавляются настройки: градиенты, размеры, закругления редактируются.
Можно развить идею, загружая и вставляя фоны в блоки.
Имхо когда редактор управляется в окне, а весь сайт в режиме реального времени во фрейме — дизайнить удобнее:)
Если будете пробовать, кнопку «Сохранить» не жмякайте — эта возможность в тестовом шаблоне отключена.
Забавно поиграться с толщиной границ блоков и градиентами — даже детям нравится:)
Тестовый шаблон с онлайн редактированием:
fromgomel.com/edit_skin_test/
Суть в том, что в стандартный 2-колоночный шаблон добавляются настройки: градиенты, размеры, закругления редактируются.
Можно развить идею, загружая и вставляя фоны в блоки.
Имхо когда редактор управляется в окне, а весь сайт в режиме реального времени во фрейме — дизайнить удобнее:)
Если будете пробовать, кнопку «Сохранить» не жмякайте — эта возможность в тестовом шаблоне отключена.
Забавно поиграться с толщиной границ блоков и градиентами — даже детям нравится:)
мне кажется тут так:
— если это инструмент для конечного пользователя то он требует слишком мелкие действия в результате которых очень легко ошибится — а значит конечный пользователь не увидит выгоды.
— если это инструмент для дизайнера/верстальщика то им может показатся что это слишком слабый инструмент.
поищите чтонибуть подобное на envato — увидите как реагируют пользователи на такое.
— если это инструмент для конечного пользователя то он требует слишком мелкие действия в результате которых очень легко ошибится — а значит конечный пользователь не увидит выгоды.
— если это инструмент для дизайнера/верстальщика то им может показатся что это слишком слабый инструмент.
поищите чтонибуть подобное на envato — увидите как реагируют пользователи на такое.
Да, мой инструмент другой — для пользователя, не верстальщика.
Он не позволяет редактировать скелет шаблона, только изменить готовый, и максимально упрощённо (большинство параметров вычисляются, а не задаются, чтобы не пугать пользователя большим количеством настроек).
Это больше заготовка, поэтому и назвал «мини-поделие».
Мне было интересно поиграться с шаблоном таким образом, и для интереса хочу прикрутить к поделке скрипт, задающий предустановленные цветовые схемы. Потом — сохранение вариантов готовых шаблонов. Потом — закачку фонов к блокам и настройка их отображения.
В принципе, двухколоночных сайтов много в интернете, и такой подход тоже может найти потребителя.
Однако у такого подхода есть существенный недостаток — он привязан к шаблону, в отличие от Вашего композёра.
Он не позволяет редактировать скелет шаблона, только изменить готовый, и максимально упрощённо (большинство параметров вычисляются, а не задаются, чтобы не пугать пользователя большим количеством настроек).
Это больше заготовка, поэтому и назвал «мини-поделие».
Мне было интересно поиграться с шаблоном таким образом, и для интереса хочу прикрутить к поделке скрипт, задающий предустановленные цветовые схемы. Потом — сохранение вариантов готовых шаблонов. Потом — закачку фонов к блокам и настройка их отображения.
В принципе, двухколоночных сайтов много в интернете, и такой подход тоже может найти потребителя.
Однако у такого подхода есть существенный недостаток — он привязан к шаблону, в отличие от Вашего композёра.
просто интересно, а кроме вас и visual Composer — много ли таких редакторов на том же envato?
Просто оставлю эту ссылочку тут www.odoo.com/page/website-builder
На мой взгляд очень юзабельный редактор. Но к сожалению он интегрирован в сам фреймворк и в своих проектах просто как js его не заюзать.
На мой взгляд очень юзабельный редактор. Но к сожалению он интегрирован в сам фреймворк и в своих проектах просто как js его не заюзать.
Sign up to leave a comment.
azexo