Модуль "Управление веб-компонентами"

Дмитрий, добрый день, а какие компоненты (JS библиотеки) использовались при разработке вашего решения?

В частности интересует редактор с подсветкой кода и автодополнением.

В качестве редактора использовался CodeMirror.

Много раз перечитывал но так и не смог понять чем это решение вообще может быть полезно.

1) "во встроенном редакторе нам доступна объектная модель DIRECTUM" - в каком редакторе? Почему проще и легче?

2) где указывается сценарий для подготовки данных, которые в веб-контроле отображаются?

3) версионность?

4) кэширование? 

5) удобный перенос между экземплярами Directum? Описанный способ не будет работать корректно если структура файлов изменилась.

6) Чем это лучше простого хранения файлов как структуры папок? Только строенным редактором с подсветкой? Редактор можно на форму ТКД вставить, так даже удобнее: хочешь карточку открываешь со встроенным редактором, хочешь файл во внешнем редакторе. Экспорт-импорт в системе уже есть. 

ИМХО эта заявка типа "Я взял вот эту крутую готовую штуку, вставил ее вот сюда. Смотрите как круто получилось!". Без проработки вопроса, без какой-то уникальной разработки, работы максимум на 1 день.

Ну а вы как храните и отлаживаете свои веб-контролы, когда они должны взаимодействовать с карточкой записи справочника, например? Я свой обычный способ описал тут:

Под встроенным редактором тут понимается редактор с подсветкой синтаксиса, используемый в решении. Проще и легче, потому что можно открыть карточку с кодом веб-контрола, внести изменения. Затем переключиться в карточку, в которую встроен веб-контрол и обновив его, увидеть изменения. При всем при этом можно использовать в коде взаимодействие с ОМ DIRECTUM и с реквизитами карточки, а не вставлять в этих местах куски данных, как если бы вы отлаживали веб-контрол отдельно от системы.

Какой еще сценарий?! Нет там никакого сценария. В описании решения указано, что для отображения веб-контрола используется функция и приведен скриншот ее хелпа. Вызывать функцию надо в том месте кода, где необходимо обновить веб-контрол, например, в событии Форма - Показ. Функция показывает содержимое веб-контрола, а не встроенный редактор с подсветкой кода.

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

Зачем?! Что вы под этим подразумеваете?

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

Вот этот пункт совсем не понял. "Хранение файлов как структуры папок" - это вы предлагаете хранить код веб-контрола в виде зип-архива в системе что ли? Причем тут ТКД и возможности экспорта/импорта в системе тоже не понял. Или имеется в виду редактор в карточке документа для зип-архива? Экспорт и импорт реализованный в решении, это совсем не то, что используется при импорте/экспорте документов.

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

Аналогично. Несколько раз перечитал ваши вопросы и выводы к ним, но так и не понял о чем вы вобще. Но все же, перед тем как высказать свое "ИМХО", решил сначала уточнить, что вы имели в виду... 

Ну, а если по существу, если вы не поняли для чего это решение и как оно реализовано, то гораздо этичнее было бы задать наводящие вопросы, или предложить какое-нибудь развитие решения, или иную его реализацию. "ИМХО" тут явно было лишним...

1) Отлаживать очень удобно просто делая navigate веб-контрола на index.html в локальной папке со всеми файлами веб-контрола на диске. Изменил файл в любом удобном редакторе -> F5 в карточке с веб-контролом и всё. А единственный полноценный способ отладки - это открытие веб-контрола в IE. При этом в веб-контроле текущую запись получаем не через window.external.Form.View.Component, а Application = new ActiveXObject("SBLogon.LoginPoint").GetApplication("ServerName=;DBName=;IsOSAuth=") и тд. Так что мне не очень понятно почему "На текущий момент отлаживать веб-контрол можно только с помощью имитации работы объектной модели DIRECTUM, путем встраивания тестовых наборов данных прямо в файлы проекта, которые после отладки необходимо будет удалить."

2) Через ОМ не всё сделать можно, поэтому надо либо в карточку, где размещается веб-контрол, добавлять действия (Actions), либо делать отдельный сценарий для веб-контрола, который будет выполнять нужную логику. Сценарий, в отличие от Action, из JS выполняется асинхронно, то есть не подвешивает карточку. Частенько в веб-контроле какой-то отчет/сводка отображается, на формирование которых уходит время. Поэтому содержимое веб-контрола надо получать асинхронно, чтобы не задерживать открытие карточки. Это я к тому, что сценарий - неотъемлемая часть веб-контрола и должна быть возможность отредактировать его так же быстро, как и остальные файлы.

3) А при хранении веб-контрола как структуру документов и папок Directum версионность есть. Это пересекается с пунктом 6, я там имел ввиду не zip-архив со всеми файлами, а по документу на каждый файл.

4) Затем что многие разработчики любят тяжелые фреймворки, которые позволяют сделать то что им надо в пару строчек (и без глубокого понимания что там происходит). Скорость системы сильно падает (а при не самом быстром интернет соединении просто катастрофически) при открытии карточки с таким веб-контролом. Тормоза особо сильно заметны при переходе между записями справочника, ведь каждый раз с сервера подгружается десяток файлов весом в пару сотен килобайт (и это хорошо если одним запросом, иначе кроме ширины канала еще RTT важен), потом сохраняется на диск, а потом уже делается Navigate. А потом пользователи жалуются что у них всё тормозит, начальство системой недовольно, не особо хочет ее развивать. Не думать о производительности = не думать о будущем. 
Можно, кстати, просто справочник сделать кэшируемым. 

5) При экспорте файлов на диск и импорте их в другую систему переносятся только имя файла и папка. Гораздо логичнее делать экспорт-импорт записей справочников, предварительно сделать тип нумерации "Ручная". Простой пример: перенесли файл из одной папки в другую. Если делать через экспорт структуры файлов на диск, то при импорте система не сможет понять что это не новый файл, а старый перенесли. Тут, конечно, можно опираться на имя файла, но не стоит.

6) Я имел ввиду перенести структуру файлов на диске в структуру объектов Directum: папок и документов. Один файл = один документ. При таком подходе есть версионность, можно использовать один и тот же набор файлов (стили, фреймворки) в разных веб-контролах. На карточке ТКД можно разместить этот же редактор. По сути документ лучше тем, что в нем уже есть контейнер для версионности и более наглядная структура файлов. Я ни в коем случае не говорю что так надо делать, это так, на вскидку.

Я так и не понял что значит "во встроенном редакторе нам доступна объектная модель DIRECTUM.".
Давайте по порядку:
"во встроенном редакторе" - это в CodeMirror который?
"нам" - кому это нам? Разработчику? Или JS в веб-контроле?
и зачем оно нам, чем нас не устраивают те способы, что я описал в п.1

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

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

А нужна ли версионность для веб-контрола? За 4 месяца использования решения она нам пока ни разу не понадобилась. Если возникнет необходимость, то подумаем над ее реализацией.

Согласен, что про производительность не надо забывать. Опять же, если работа с системой осуществляется в локальной сети и с учетом того, что содержимое веб-контрола можно получить сценарием асинхронно, то вроде как не критично. Кроме того, вы и сами уже как-то в комментариях одной из статей показывали, что можно писать данные напрямую в веб-контрол, минуя промежуточное сохранение файлов на диск. В решении как раз этот способ тоже используется. Про кеширование теперь тоже стало все понятно.

Изначально переносить веб-контролы между системами мы и собирались через экспорт\импорт записей справочников. Но столкнулись с проблемой, что если в табличной части записи справочника есть заполненные строки, то после переноса веб-контрола, в такую таблицу нет возможности добавить новые строки. Возникает исключение неуникальности ключа при добавлении новой строки, т.е. система почему-то считала, что в таблице записей нет. Разбираться с этой проблемой времени не было (версия системы 5.2.0) и сделали еще один альтернативный способ переноса веб-контролов. Естественно, как будет устранена проблема, то переносить веб-контролы можно будет и через экспорт\импорт записей справочника. Однако, заносить новые веб-контролы в систему, для данного решения, очень удобно именно через реализованный импорт. Указал папку с проектом, все автоматически занеслось в нужные справочники.

Вариант с хранением файлов веб-контролов в виде документов системы, я даже рассматривать не стал, по причине того, что придется управлять правами доступа на такие документы, причем на каждый в отдельности. Помимо этого, возникнет куча проблем с тем чтобы собрать все это хозяйство в один проект и потом еще и поддерживать его в актуальном состоянии. Конечно, если сесть и подумать, то все эти проблемы можно решить тем или иным способом, но решение получится гораздо более сложным, чем это. Но идея с повторным использованием элементов одного веб-контрола в других веб-контролах мне понравилась, надо будет обязательно реализовать подобную "фичу" в этом решении.

Да

А разве в текущем контексте это не одно и то же?

Про способ, описанный в п.1 я до сегодняшнего дня не знал (ну или не догадался, как вам удобнее). Как говориться, "век живи - век учись" :)

В плане хранения веб-контролов, вариант используемый в решении более прост в реализации, достаточно функционален и помимо хранения веб-контролов бонусом дает дополнительные возможности для их отладки, а изначально решение и задумывалось именно как хранилище для веб-контролов. Из плюсов возможностей отладки веб-контролов в данном решении, хотелось бы отметить то, что нет привязки к конкретной папке на локальном диске и можно отлаживать веб-контрол не внося никаких изменений в прикладной код (если это, конечно, не потребуется при отладке самого веб-контрола). Если прикрутить блокировки, то в моем решении можно вести разработку веб-контрола коллективно (можно вести совместную разработку и без блокировок, но тогда как и в предыдущих версиях  Directum, "кто последний сохранил, тот и папа"), без необходимости хранить копию веб-контрола на локальном диске каждого разработчика. Ваш вариант можно тоже доработать, используя, например, сетевую папку, но это уже тема отдельной дискуссии. Во всем остальном, чтобы сравнить надо попробовать оба способа.  

1) Отладка непосредственно в IE нужна когда много JS кода и непонятно что сломалось. В веб-контроле на карточке нельзя включить отладку/консоль JS, поэтому в IE (другие браузеры ActiveX не поддерживают) приходится получать запись и работать с ней.

3) Версионность она как бекапы, не нужна пока не случится ситуация когда будет непонятно почему всё сломалось, ведь раньше работало. Ну чтобы понять когда какой-то кусок кода появился. В общем не стоит придерживаться "Гром не грянет, крестьянин не перекрестится."

4) Ну в общем надо справочник делать кэшируемым и работать с ним через CreateCachedReference(). Обычно делаю все веб-контролы очень простыми, на чистом JS. Тогда HTML+CSS+JS+(data:image/;base64 всех картинок) нормально можно хранить в функции ничего не выгружая на диск и не загружая с сервера (функции как и остальная разработка кэшируются).

5) Да, есть проблемы с импортом записей справочников с детальным разделом, я немного с другой встречался, мы везде доработали сценарий импорта.

6) "Конечно, если сесть и подумать" - мне кажется это надо было сделать до публикации на Awards, это ж не просто статья, а материал, который должен претендовать звание чего-то больше, чем сделанного на коленке решения. Вот стали бы Вы публиковать это решение если бы не красивый редактор?

Пища для размышлений: можно хранить весь веб-контрол одним архивом в документе. Есть версионность, прав не нужно, т.к. тело можно SQL-запросом вытащить. Для отладки в ТКД сделать кнопочку "Начать режим отладки" при нажатии на которую архив выгружается и распаковывается, открывается в проводнике. В этот момент в реквизиты ТКД записывается путь к выгруженным файлам и имя текущего пользователя и функция MTGWBCShowContent() будет знать что для этого пользователя не надо выгружать тело файла, а просто делать Navigate в указанную папку. То есть можно будет редактировать файлы на диске и сразу результат наблюдать. Ну и кнопочку "Завершить режим отладки", которая очистит реквизиты и спросит, сохранить ли сделанные изменения (импортом в новую или текущую версию). Если уж очень хочется, то можно и редактор на карточку ТКД вынести, с переключением между файлами. Так и для обложек ничего придумывать не надо.

Вы меня опять неправильно поняли. "Сесть и подумать" - это я вам предлагал, на случай, если вы захотите развить свой вариант решения данной задачи. Над своим вариантом я уже подумал и результат работы выложил тут и совсем не считаю его сделанным на коленке. Это мое видение решения проблемы и я вам его не навязываю. У вас есть свое видение решения проблемы, так вам никто не мешает реализовать свой вариант и опубликовать его на этом конкурсе, благо время позволяет. Что касается, стал бы я его публиковать при отсутствии редактора, то разумеется стал бы. Данное решение является небольшой частью других решений, которые будут выложены чуть позже, со ссылкой на это решение. Если вам кажется, что проделано недостаточно работы, то если вы взгляните на условия конкурса, то там нет никаких ограничений на размер разработки. Кто-то выкладывает просто типовой маршрут или сценарий, а кто-то целые бизнес-решения, но и те и другие считают свои решения определенным достижением в своем творчестве. Уровень программирования и опыт разработки тут у всех разный, что и является одним из плюсов данной платформы, т.к. уровень вхождения в разработку достаточно невысок. Помимо всего прочего, данное решение было опубликовано с целью узнать, что я делаю не так и в каком направлении стоит дальше двигаться. Ваше мнение я услышал, сделал для себя соответствующие выводы.

В любом случае спасибо, общение с вами было весьма познавательным.

Выскажу свой опыт. У нас пока не так много разработок с использованием WebBrowserControl. Однако, их число растет. Есть необходимость синхронизировать разработки с другой организацией. Поэтому, о чем то подобном, а именно: о диспетчере файлов Web разработки тоже начал задумываться.

Тут несколько моментов. Мы придерживаемся "старой" и "не модной" технологии выгрузки файлов в Temp и Navigate на них, так как в Abou:blank не поработать с относительными путями на изображения, CSS и JS. Файлы разработки у нас хранятся как документы, доступные всем пользователям. Есть набор функций аля "__CreateJQuery", в которых захардкодено ИД документа и если такого документа нет, то он выгружается в Temp. JS библиотеки, состоящие из многих файлов и папок храним как zip или sfx архивы и так же распаковываем их в Temp.

Проблем в таком подходе много и самая большая для нас сейчас - это ИД документа в коде функции. Перенести с тестовой на рабочую, или передать в другую организацию разработку? Требуется инструкция, как привести разработку в рабочее состояние. 

Поэтом, решение Дмитрия привлекло внимание и получило мое субъективное одобрение. Он решил одну из тех проблем, с которой сталкиваюсь я. И сделал это красиво. С редактором кода и прочими фишками...

Михаил, "ИД документа в коде функции" - зачем, если есть константы или можно документам назначать уникальный код, тогда в функции ничего менять не надо, только при первом импорте заполнить в документе строковый реквизит (всего 1 раз)? Это решает Вашу проблему с ИД?
При переносе между экземплярами систем без написания своего сценария переноса что-то делать да придется: либо найти запись справочника, в которую надо импортнуть (Дмитрий же отказался от переноса записей справочника вместо того чтобы исправить сценарий импорта), либо документ.  Свои сценарии экспорта/импорта документов сделать довольно легко, порядка десятка-двух строк кода.

Если убрать красивый редактор кода, то решение ничего по сути не делает (не упрощает жизнь), кроме выгрузки файлов на диск и navigate в веб-контроле. За несколько часов разработки (ну максимум день с тестированием) можно сделать и это и решить насущную проблему с переносом и сделать ТКД для удобной отладки и редактирования, которую я выше описал.

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

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

Уверяю вас, я потратил на разработку гораздо больше времени, но вы выбрали весьма оригинальный способ похвастаться своими профессиональными навыками. Лично я считаю, что хранение веб-контролов в виде документов плохая идея, но своего мнения вам не навязываю и не считаю его единственным верным решением. Предлагаю вам все же поучаствовать в этом конкурсе, чтобы все убедились в ваших высоких профессиональных навыках проектирования и разработки не на словах, а на деле.

Дмитрий, 5 баллов! Красиво закончил)