Mimic — скрипты для SVG

[manjey73]

Информативность консоли на данный момент для меня нулевая. А тот же Сан-компонент мало что проясняет как пример, потому что он примитивен.
Нет применения let, const, как правильно проводить поиск по html коду, в том числе и по svg, например почему именно svg path, а не просто path? И так далее.

[Mikhail]

Нет применения let, const, как правильно проводить поиск по html коду, в том числе и по svg, например почему именно svg path, а не просто path?

Ответы на такие общие вопросы по программированию, мне кажется, можно за секунды узнать у нейросетки. Здесь даже специфика скады отсутствует. Чистый HTML, JavaScript, jQuery и SVG.

• Ответ изменён 6 месяцев, 1 неделя назад пользователем Mikhail.

[Mikhail]

К разработке Редактора схем планирую вернуться после праздников, сейчас работаю над другими задачами.

[manjey73]

Ответы на такие общие вопросы по программированию, мне кажется, можно за секунды узнать у нейросетки

Речь не о применении этих вещей в javascript, а как правильно и в каких местах их прописывать в окнах редактора скриптов в Mimic

У меня пока идут ошибки — не знаю токен <scipt>, не знаю, что такое const, не знаю такой переменной или вообще — ошибка мнемосхемы.

При этом все это работает в html странице.

• Ответ изменён 6 месяцев, 1 неделя назад пользователем manjey73.

[manjey73]

Очередная ошибка в консоли на строки скрипта из html, в котором все работает 🙁

liquidRect.setAttribute is not a function

куда еще пошлете изучать язык?

з.ы. честно не знаю, как еще донести вопрос программисту от:

столяр, строительный плотник
сборщик радиоэлектронной аппаратуры
сантехник
электрик
сборщик и настройщик ПК ZX-Spectrum
монтажник СКС
Проектировщик (СКС, электрика)
и даже грузчик и экспедитор 🙂

Почему не работает функция, которая работает в принципе в javascript ?

setAttribute, document.getElementById (что тут нужно вместо document ?)

в общем очередная попытка — объясните «синтаксис» или какие-то правила Mimic обертки javascript, чтобы они заработали как они работают в html

[manjey73]

кое-что заработало, кроме getElementById и setAttribute

вроде вариант поиска, которые вы указали работает (не проверил на двух экземплярах). Но хотелось бы без особых танцев с бубнами просто переносить код, который работает из коробки в html.
подстроив под правила обёртки в виде обработчика скрипта в Mimic.

[Mikhail]

Интернет утверждает, что атрибут id должен быть уникален в пределах страницы. Даже для SVG. Поэтому если в SVG есть id, попробуйте заменить их на class.

[manjey73]

класс ссылается на стиль, это вроде как разные вещи в svg.

[manjey73]

Ну и попробовал два faceplate с одним и тем же svg в коде ExtraMarkup.

Соответственно добавил канал 1302 по аналогии. Скрипт один, управляются по разному.

з.ы. но чего-то не хватает, но понять чего не могу 🙂 точнее описать.

[manjey73]

Картинка из проектов

Собственно вот, имеем AMF 1.ХХХХ и AMF 2.XXXX и далее 3, 4 и т.д.
(например на одном проекте у меня 8 шт ДГУ).

На картинке видно, что каналов управления здесь минимум 5 шт.
Каналов для данных еще > 25-ти кроме управления.

Теперь вопрос — как создать faceplate на все это хозяйство, чтобы:

1. Выполнить привязку минимумом переменных — например отправить только № объекта или несколько № устройств.
2. И вишенка на торте. Все мы люди, одни русские, другие турки, третьи китайцы и так далее. Как вместо имен Тегов внутри компонентов, вставленных внутри faceplate использовать не имена Тегов а какие-то символьные переменные? чтобы faceplate получился действительно универсальным и его мог использовать любой человек.
Например не переписывал весь facplate и кучу переменных под себя, а настроил (отредактировав) всего один файлик, где были бы указаны символьные переменные, используемые в компонентах для привязок переменных со своими реальными именами тегов? Заодно чтобы там можно было оставить комментарий при создании facplate. Которыми человек привык пользоваться. А так же менять подобный файлик связи для другого экземпляра этого же faceplate ?

ну что-то вроде шаблона для faceplate по аналогии с шаблонами для Modbus драйвера.

То есть свести к минимуму ковыряние в коде, да и вообще в недрах faceplate, разбираясь что к чему относится. То есть автор faceplate так скажем сохранит в нем же «подсказки»…

Ну и собственно люди тогда действительно смогут делиться и это будет наполнять базу компонентов….

[Mikhail]

Пример:
https://ibb.co/CsHt0R7S

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

Если оформить в качестве фейсплейта крупный блок (выделено красным), то такой фейсплейт окажется, скорее всего, специфичен для конкретного проекта. У него будет большое количество экспортируемых свойств, которые в процессе создания фейсплейта нужно привязать к свойствам его дочерних компонентов. После того, как фейсплейт добавлен на схему, потребуется настроить привязки, указав для каждого свойства код объекта. Далее копировать экземпляр фейсплейта, чтобы привязки тоже скопировались. Возможно, данный способ неидеален. Нужно подумать, как ещё можно реализовать привязки для фейсплейтов, которые специфичны для проекта и имеют большое количество свойств.

[manjey73]

Вот хотелось бы сделать все в одном.
И в идеале, чтобы скрипты тоже понимали и умели работать со ссылочными именами, а не с прямыми кодами тегов.

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

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

[manjey73]

Например кондиционер, от 50 до 100 переменных. Где есть и управление не в единственном числе. Всякие уставки. И таких кондиционеров, штук 40.
При этом на другом объекте могут быть другие кондиционеры, где не будет части параметров, или будут какие-то свои.
А faceplate при этом хочется сделать один и универсальный, а не плодить их сущности.

То же относится к ДГУ, к ИБП, щитам с анализаторами.

[manjey73]

> Если оформить в качестве фейсплейта крупный блок (выделено красным), то такой фейсплейт окажется, скорее всего, специфичен для конкретного проекта. У него будет большое количество экспортируемых свойств, которые в процессе создания фейсплейта нужно привязать к свойствам его дочерних компонентов

Вот вся соль и состоит в том, чтобы экспортируемое свойство было всего ОДНО.
И мы в качестве экспортируемого свойства просто передадим НОМЕР устройства.
Далее все необходимые переменные этого устройства должен забрать какой-то механизм faceplate-а

пусть даже какой-то скрипт, но не портянка на пару листов А4.

не знаю, как еще объяснить. Вот есть счетчик (устройство №3 к примеру), у него есть:
Ток Л1, Ток Л2, Ток Л3
Мощность Л1, Мощность Л2, Мощность Л3 и т.д. и т.п.

В качестве экспортируемого свойства будет Объект — передаем туда номер устройства.
Скрипт или механизм самого faceplate или главной схеме передает все данные этого устройства, или скажем так запрашивает у сервера всю пачку и куда-то складывает.
Внутри фейсплейта мы делаем что-то типа Объект.Мощность Л1 -> @pl1 (некая символическая ссылка) которую мы и будем указывать в компонентах внутри фейсплейта в качестве источника данных ВМЕСТО прямой записи коде тега той самой переменной Мощность Л1.

соответственно если главная схема видит, что у нас 2-3 экземпляра просят данные одного и того же Объект то она рассылает всем экземплярам то, что у сервера будет запрашивать один раз.

Как-то указывать, что это канал управления. Опять же, главная схема должна «слушать» изменения этих переменных от экземпляров и перенаправлять полученные команды обратно в сервер.

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

Например в одном машинном зале ЦОД будут кондиционеры с увлажнителями и без них, это норма для ЦОДов. ИБП могут отличаться в одном проекте. для IT одни, для инженерки другие и т.д. а общих характеристик и переменных у них вагон и маленькая тележка. И вот это все постоянно настраивать просто занимает кучу времени.

[manjey73]

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

Ну вот как с драйверами пример. Драйвер один, просто разные шаблоны.
Вот так же подойти — Faceplate один, а шаблоны разные.

[Автор]

Сообщения