Понял. Вот в data-атрибутах для запуска виджетов во фронтенде я вообще ничего плохого не вижу, и даже считаю это правильным. Сам так делаю.
Вот на счет редактора — да, тут не очень красиво.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Это не исправит проблему, но сделает ее менее страшной.
Возможно, сам подход — хранить данные в HTML не совсем правильный.
Получается, что смешивается модель с видом.
Что, если для последующего открытия страницы в редакторе экспортировать страницу в JSON, а при открытии — импортировать из JSON?
Так у вас будет больше возможностей по работе с версиями виджетов.
Я, например, в JSON сохраняю и версии виджетов, а при импорте, если есть более новая версия виджета, выполняю простую миграцию, которая приводит старый формат данных виджета к новому, например, добавляет поля, удаляет, переименовывает и т.д.
А я сразу пошел по лендингам, и старался делать все для более простых пользователей. Не для верстальщиков и программистов, тогда все по другому, я думаю, выглядело бы.
Если говорить о других различиях, то вы виджеты рендерите один раз при инициации, и далее при каждом изменении настроек.
У меня виджеты и секции — шаблоны AngularJS, который при изменении настройки перерисовывает только ту часть шаблона, которая меняется в следствие изменения настройки.
Такой подход упрощает работу с шаблонами, но вот плагины интегрировать сложнее)
При изменении настройки мне нужно будет вызывать функцию интегрируемого плагина, которая произведет необходимые изменения в соответствии с изменением настройки. А если настроек много, то для каждой из них мне нужно будет делать подобные «нити», связывающие изменения настроек с функциями плагина, реализующими их.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
Да, все же тут сложность в том, что и редактор и все плагины работают одновременно.
Как вариант, можно «перекрывать» все сеткой, которая визуально показывает, где что.
У меня кнопки секций видны всегда, виджетов — по наведению, а обводка у виджетов видна всегда, + разделители колонок всегда видны.
Благодаря этому можно быстро определить структуру страницы.
Обратил внимание, что у вас реализованы анимации с обширными настройками — отпала челюсть)
Внешность нужно подтянуть, потому что она мешает воспринимать серьезно весь функционал.
Редактор интересный. Интерфейс страшноватый (видно, что программист делал), но разобраться можно.
Особенно пугают вот такие штуки:
Являюсь автором похожего редактора, но немного другой направленности, поэтому примерно представляю, с какими трудностями пришлось столкнуться.
Обратил внимание на относительно небольшое потребление памяти, и отсутствие каких то явных утечек — вы явно над этим работали :)
Если удалить все секции на странице, то при попытке добавить 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», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
То, что редактор работает с работающими плагинами — очень круто, хотя и может быть затратно с точки зрения производительности.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Вот на счет редактора — да, тут не очень красиво.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Это не исправит проблему, но сделает ее менее страшной.
Возможно, сам подход — хранить данные в HTML не совсем правильный.
Получается, что смешивается модель с видом.
Что, если для последующего открытия страницы в редакторе экспортировать страницу в JSON, а при открытии — импортировать из JSON?
Так у вас будет больше возможностей по работе с версиями виджетов.
Я, например, в JSON сохраняю и версии виджетов, а при импорте, если есть более новая версия виджета, выполняю простую миграцию, которая приводит старый формат данных виджета к новому, например, добавляет поля, удаляет, переименовывает и т.д.
Ого!
Подозрительная, кстати, штука:
То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда?
Правильно я понял предназначение этих атрибутов?
Если говорить о других различиях, то вы виджеты рендерите один раз при инициации, и далее при каждом изменении настроек.
У меня виджеты и секции — шаблоны AngularJS, который при изменении настройки перерисовывает только ту часть шаблона, которая меняется в следствие изменения настройки.
Такой подход упрощает работу с шаблонами, но вот плагины интегрировать сложнее)
При изменении настройки мне нужно будет вызывать функцию интегрируемого плагина, которая произведет необходимые изменения в соответствии с изменением настройки. А если настроек много, то для каждой из них мне нужно будет делать подобные «нити», связывающие изменения настроек с функциями плагина, реализующими их.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
Да, все же тут сложность в том, что и редактор и все плагины работают одновременно.
Как вариант, можно «перекрывать» все сеткой, которая визуально показывает, где что.
У меня кнопки секций видны всегда, виджетов — по наведению, а обводка у виджетов видна всегда, + разделители колонок всегда видны.
Благодаря этому можно быстро определить структуру страницы.
Обратил внимание, что у вас реализованы анимации с обширными настройками — отпала челюсть)
Внешность нужно подтянуть, потому что она мешает воспринимать серьезно весь функционал.
Для примера, вот есть такой редактор: plugnedit.com
Он достаточно функциональный, если с ним поработать немного, но дизайн портит все.
Особенно пугают вот такие штуки:
Являюсь автором похожего редактора, но немного другой направленности, поэтому примерно представляю, с какими трудностями пришлось столкнуться.
Обратил внимание на относительно небольшое потребление памяти, и отсутствие каких то явных утечек — вы явно над этим работали :)
Если удалить все секции на странице, то при попытке добавить 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», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
То, что редактор работает с работающими плагинами — очень круто, хотя и может быть затратно с точки зрения производительности.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Какие планы по дальнейшему развитию?
Очень здорово скобки цветом выделяются!
Timeline удобен для определения того, есть ли вообще утечки. В нем, кстати, можно вызвать сборку мусора вручную:
А Record Heap Allocations больше применим для определения того, какое конкретно действие сколько памяти откладывает.