artifex 25 сентября 2014 в 13:11
+3
piumosso разработал нечто схожее (http://futurecolors.ru/belonika/), можете пообщаться на счёт логики и производительности.
- andy133 26 сентября 2014 в 06:50
  0
  Спасибо. Я посмотрел видео — выглядит интересно.
macik_spb 25 сентября 2014 в 13:22
+2
Думаю здесь будет полезна прямая ссылка на демо — azexo.com/azexo_composer/
- andy133 26 сентября 2014 в 06:46
  0
  Постеснялся добавить — там всетаки упоминания продуктов в которых используется эта библиотека.
kemsky 26 сентября 2014 в 01:38
0
итоговый исходник на JS имеет красивую и компактную ООП архитектуру

После этого я был слегка удивлен увидев исходники по 6к строк.
- andy133 26 сентября 2014 в 06:07
  0
  Конечно я имел ввиду в сравнении с существующими билдерами.
  - andy133 26 сентября 2014 в 06:19
    
    0
    Если можете сказать хотя бы одну идею как это все можно сократить то устраивающего вас размера — я с удовольствием готов обсудить. Я про это так и написал в конце статьи — это открытый вопрос.
grimalschi 26 сентября 2014 в 02:51
+1
Редактор интересный. Интерфейс страшноватый (видно, что программист делал), но разобраться можно.

Особенно пугают вот такие штуки:

Являюсь автором похожего редактора, но немного другой направленности, поэтому примерно представляю, с какими трудностями пришлось столкнуться.

Обратил внимание на относительно небольшое потребление памяти, и отсутствие каких то явных утечек — вы явно над этим работали :)

Если удалить все секции на странице, то при попытке добавить 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», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.

Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.

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

Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.

Какие планы по дальнейшему развитию?
- andy133 26 сентября 2014 в 07:46
  +1
  Особенно пугают вот такие штуки:
  
  Вы очередной раз подвердили что мне надо срочно занятся этой проблемой. Ставлю высший приоритет в моем плане.
  
  «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
  
  У вас какой проект если не секрет?
  - grimalschi 26 сентября 2014 в 12:21
    
    0
    Я занимаюсь редактором platformalp.ru
    
    Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
    
    Да, все же тут сложность в том, что и редактор и все плагины работают одновременно.
    
    Как вариант, можно «перекрывать» все сеткой, которая визуально показывает, где что.
    
    У меня кнопки секций видны всегда, виджетов — по наведению, а обводка у виджетов видна всегда, + разделители колонок всегда видны.
    
    Благодаря этому можно быстро определить структуру страницы.
    
    Обратил внимание, что у вас реализованы анимации с обширными настройками — отпала челюсть)
    
    Внешность нужно подтянуть, потому что она мешает воспринимать серьезно весь функционал.
    
    Для примера, вот есть такой редактор: plugnedit.com
    
    Он достаточно функциональный, если с ним поработать немного, но дизайн портит все.
    - andy133 27 сентября 2014 в 09:07
      
      0
      
      Спасибо за предложения.
      Вообщето ваш проект очень близок к моему.
      Я ставил целью делать редактор и для лендингов тоже.
      Едиственное в чем различие, что я ставил еще цель делать редактор для специалистов тоже: дизайнеров, верстальщиков и программистов.
      
      Я сейчас уберу нагромождение кнопок и скоро будет новая фича слайдер-презентация на основе Impress.JS (как обычно с визуальным редактором).
      
      И может быть вас заинтересует мой проект :)
      Стабильность поддержки можно оценить анализируя рынок codecanyon
      codecanyon.net/user/azexo/portfolio
      - grimalschi 28 сентября 2014 в 23:00
        
        0
        
        А я сразу пошел по лендингам, и старался делать все для более простых пользователей. Не для верстальщиков и программистов, тогда все по другому, я думаю, выглядело бы.
        
        Если говорить о других различиях, то вы виджеты рендерите один раз при инициации, и далее при каждом изменении настроек.
        
        У меня виджеты и секции — шаблоны AngularJS, который при изменении настройки перерисовывает только ту часть шаблона, которая меняется в следствие изменения настройки.
        
        Такой подход упрощает работу с шаблонами, но вот плагины интегрировать сложнее)
        
        При изменении настройки мне нужно будет вызывать функцию интегрируемого плагина, которая произведет необходимые изменения в соответствии с изменением настройки. А если настроек много, то для каждой из них мне нужно будет делать подобные «нити», связывающие изменения настроек с функциями плагина, реализующими их.
        
        По поводу открытых вопросов, где у вас используются «data» аттрибуты?
        
        В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
        
        andy133 29 сентября 2014 в 09:19
        
        0
        
        У меня виджеты и секции — шаблоны 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 — пока отказывают изза неуникальности набора фич — кстати это одна из причин почему в моем проекте туча фич — постоянно отказывают.
        
        grimalschi 29 сентября 2014 в 12:00
        
        0
        
        можете увидеть их если откроете исходник страницы azexo.com/azexo_composer и подсветите строку «data-az».
        
        Ого!
        
        Подозрительная, кстати, штука:
        
        То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда?
        
        Правильно я понял предназначение этих атрибутов?
        
        andy133 29 сентября 2014 в 12:27
        
        0
        
        Подозрительная, кстати, штука:
        
        В этой демке много осталось не нужных атрибутов изза того что старые версии небрежно их плодили. Кстати может быть и текущая версия не все поддирает ненужное. Это все легко поправить — поэтому я поставил не высокий приоритет этому.
        
        То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда? Правильно я понял предназначение этих атрибутов?
        
        Да. Для 2х задач:
        — для запуска JS виджетов во фронтенде.
        — для их редактирования в режиме редактирования
        
        grimalschi 29 сентября 2014 в 13:14
        
        0
        
        Понял. Вот в data-атрибутах для запуска виджетов во фронтенде я вообще ничего плохого не вижу, и даже считаю это правильным. Сам так делаю.
        
        Вот на счет редактора — да, тут не очень красиво.
        
        Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
        
        Это не исправит проблему, но сделает ее менее страшной.
        
        Возможно, сам подход — хранить данные в HTML не совсем правильный.
        
        Получается, что смешивается модель с видом.
        
        Что, если для последующего открытия страницы в редакторе экспортировать страницу в JSON, а при открытии — импортировать из JSON?
        
        Так у вас будет больше возможностей по работе с версиями виджетов.
        
        Я, например, в JSON сохраняю и версии виджетов, а при импорте, если есть более новая версия виджета, выполняю простую миграцию, которая приводит старый формат данных виджета к новому, например, добавляет поля, удаляет, переименовывает и т.д.
        
        andy133 29 сентября 2014 в 14:11
        
        0
        
        Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
        
        Тут надо разделить:
        1) есть data-атрибуты которые описывают структуру модели — которая нужна во фронтенде некоторым виджетам для активации. CMS и тотже Visual Composer добавляет невостребованные классы по которым по сути можно востановить модель документа — т.е. это частое явление на сайтах.
        2) а есть data-атрибуты которые нужны были для рендерига HTML и по сути несут дублирующуюся информацию во фронтенде, просто в более формальном виде. они понадобятся только в режиме редактирования.
        
        Осюда я думаю, что такой поход кажется некрасивым больше не изза того, что смешивается модель с видом а изза подобного дублирования информации и увеличения трафика. Даже если сохранить эти данные в JSON и положить кудато в одно место — это не избавит от настоящей неприятности. Как вариант можно сделать чтобы виджеты востанавливали эти параметры не из атрибутов а из имиже отрендереного HTML — это трудности для программиста — временные затраты на не очень эффективный код — для каждого виджета свой парсер.
        
        Получается, что смешивается модель с видом.
        
        В общем я тоже чувствую что-то не так изза этого смешивания. Но конкретную проблему сформулировать не могу. Только проблема трафика, которую я написал выше, и вижу возможное решение ее не через выделение атрибутов в JSON.
        
        Похоже чтобы JS билдеру избавится от этой проблемы надо больше заставить программиста программировать — а проблема то пару % от веса страницы.
        
        andy133 30 сентября 2014 в 04:53
        
        0
        
        еще я давно обдумываю вариант фильтрации data атрибутов для анонимуса — для решения проблемы трафика.
        думаю буду фильтровать по признаку нужен ли он только для функции рендеринга виджета — придется создать такое поле у параметра.
Den1xxx 27 сентября 2014 в 18:20
+1
Хороший проект. Впечатляет. Работа проделана большая.

Пару замечаний
1. Иконка Клонировать неправильная. Должны быть две овечки или две бумажки, что ли.
Иконки копировать/вставить тоже есть же стандартные, зачем что-то другое — это же путает пользователя?
2. Всё так быстро работает, есть опасность «заредактироваться», а кнопки «Отмена» нет.
Надо бы добавить, барин. Очень этово не хватает мужикам!
3. Не нашёл локализации.

platformalp.ru/ заодно попробовал — очень понравился, главное отличие и плюс в том, что редактор не прикручен к тексту и страница не перезагружается.
Однако у этих редакторов разные цели, и сделать лучше Azexo composer трудно — там много кнопок управления, не только редактор.
Интегрирование кнопок управления в редактор повысит удобство, однако наверняка намертво привяжет к одному редактору;)

В общем и целом — проект интересный, надо бы «форкнуть».
- andy133 29 сентября 2014 в 08:54
  0
  Спасибо большое за замечания!
  Локализация — там все готово для локализации просто в этой версии не доделано.
  Спасибо за приятный отзыв!
Den1xxx 29 сентября 2014 в 14:28
0
Локализация — там все готово для локализации просто в этой версии не доделано.

Ммм… Где?
Вы ж понимаете, у проекта с локализацией совсем другой уровень.
Я б подключился.
- andy133 30 сентября 2014 в 04:58
  0
  обратите внимание на функцию «t» в исходнике.
Den1xxx 29 сентября 2014 в 14:50
0
Да, забыл показать своё мини-поделие.
Тестовый шаблон с онлайн редактированием:
fromgomel.com/edit_skin_test/
Суть в том, что в стандартный 2-колоночный шаблон добавляются настройки: градиенты, размеры, закругления редактируются.
Можно развить идею, загружая и вставляя фоны в блоки.
Имхо когда редактор управляется в окне, а весь сайт в режиме реального времени во фрейме — дизайнить удобнее:)
Если будете пробовать, кнопку «Сохранить» не жмякайте — эта возможность в тестовом шаблоне отключена.
Забавно поиграться с толщиной границ блоков и градиентами — даже детям нравится:)
- andy133 30 сентября 2014 в 05:02
  0
  мне кажется тут так:
  — если это инструмент для конечного пользователя то он требует слишком мелкие действия в результате которых очень легко ошибится — а значит конечный пользователь не увидит выгоды.
  — если это инструмент для дизайнера/верстальщика то им может показатся что это слишком слабый инструмент.
  
  поищите чтонибуть подобное на envato — увидите как реагируют пользователи на такое.
  - Den1xxx 30 сентября 2014 в 10:47
    
    0
    Да, мой инструмент другой — для пользователя, не верстальщика.
    Он не позволяет редактировать скелет шаблона, только изменить готовый, и максимально упрощённо (большинство параметров вычисляются, а не задаются, чтобы не пугать пользователя большим количеством настроек).
    Это больше заготовка, поэтому и назвал «мини-поделие».
    Мне было интересно поиграться с шаблоном таким образом, и для интереса хочу прикрутить к поделке скрипт, задающий предустановленные цветовые схемы. Потом — сохранение вариантов готовых шаблонов. Потом — закачку фонов к блокам и настройка их отображения.
    В принципе, двухколоночных сайтов много в интернете, и такой подход тоже может найти потребителя.
    Однако у такого подхода есть существенный недостаток — он привязан к шаблону, в отличие от Вашего композёра.
serjio 30 сентября 2014 в 07:04
0
просто интересно, а кроме вас и visual Composer — много ли таких редакторов на том же envato?
- andy133 30 сентября 2014 в 07:12
  0
  пару десятков будет наверно — но это зависит от того что мы под редактором имеем ввиду.
  например если учитывать редакторы в составе вордпрес-тем то может сотня будет.
voron3x 26 декабря 2014 в 14:22
0
Просто оставлю эту ссылочку тут www.odoo.com/page/website-builder
На мой взгляд очень юзабельный редактор. Но к сожалению он интегрирован в сам фреймворк и в своих проектах просто как js его не заюзать.