Формат описания однозначно нужно менять/совершенствовать. Бинарный формат нужен только если будут проблемы с производительностью. Тогда его генерацию из текстового можно делать "на лету" при установке элемента или принудительно командой после изменения параметров элемента.
Предусмотреть многоязычность в конфиге компонента.
Этот топик читают: Гость
|
Ответов: 4628
Рейтинг: 749
|
|||
| карма: 26 |
| ||
| Голосовали: | CriDos |
Ответов: 1841
Рейтинг: 369
|
|||
|
Про многоязычность я даже и подзабыл, надобно продумать хорошо этот момент.
------------ Дoбавленo в 20.12: Netspirit писал(а): Предусмотреть многоязычностьjson очень гибкая штука, однако  Вот так вот, будет реализована поддержка языков: пример на основе файла описания пакета В итоге получаем поддержку любого к-ва переводов в удобном виде. ------------ Дoбавленo в 23.53: В процессе реализации, упростил json конструкцию, убрав массивы и запихнул всё в объекты {}. Также, в случае если отсутствует интересующий ключ перевода, будет выбрал первый в списке из доступных переводов. |
|||
| карма: 1 |
|
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
|
Galkov писал(а): Единственное "нетупиковое" направление -- среда написанная на самом языке HiAsm.Если использовать для этого «Hyper» элементы то, наверное, можно. Под понятием «Hyper» элемента имею в виду что-то вроде HiAsmSDK пакета Windows и SDK пакета CNET: эксперименты с SDK |
|||
| карма: 6 |
|
Ответов: 2125
Рейтинг: 159
|
|||
|
CriDos писал(а): Вот так вот, будет реализована поддержка языков:Пихать разные языки в один файл - не лучшая идея. Поддержка языковых файлов (один язык - один файл) де факто является стандартом. |
|||
| карма: 1 |
| ||
| Голосовали: | CriDos |
|
Ответов: 1841
Рейтинг: 369
|
|||
|
tsdima, в общем, согласен.
В случае если будем иметь большое к-во переводов, выйдет не очень хорошо...  ...Однако, реализовать данный вариант наиболее сложнее, ибо все ключи (названия функционала) к которым будут привязаны переводы, будут динамическими (определяться пользователями/разработчиками). Думаю, тут можно сделать следующим образом: Ну и состояния тоже тогда стоит поместить в суб директорию, ведь их может быть довольно много. |
|||
| карма: 1 |
|
Ответов: 964
Рейтинг: 12
|
|||
|
Насчет чего-то своего "по мотивам" хайасма я тоже почти созрел для собственной "попытки к бегству" но я считаю что нужно идти от КОДА к СХЕМЕ .
Точнее попытаться реализовать трансляцию произвольного кода на ЯВУ в схему и обратно . (Причем генерируемый код должен быть ВНЯТНЫМ хорошо структурированным Все схема-технические настройки и структурные надстройки можно прятать в промежуточный "грязный-код" в виде комментариев то есть в принципе не будет некого промежуточного не чем не компилируемого кода ) Чем такой подход хорош ? 1 Тем что можно легко преходить от схемы к коду и обратно без потери качества того и другого . ( Посмотрел и поправил в графике потом вернулся к коду вел несколько формул и вернулся обратно в графический схемо-код ) 2 Тем что можно легко переходить от одного ЯВУ к другому (По сути мы по совместительству получим "универсальный переводчик" практически между любыми языками программирования ) 3 Все структурные надстройки и дополнения(на пример визуальную генерацию форм ) можно вводить без изменения в ядре механизмов трансляции схем в яву (где забит только самый низкий уровень) по сути добавляя только шаблон-макрос) Минусы 1 Не вполне понятна архитектура самого схемотехнического языка (То есть понятно что на нижнем уровне должен быть отражен каждый основной элемент ЯВУ (if for while case := Var Type и тд ) Но совершенно понятно что на среднем и высоком уровне должно быть что-то иное иначе теряется удобство схемотехнического стиля ) 2 Есть желание полностью избавится от "стековой пробки " и "кольцевания" как главных бичей Хайасма Сделать нормальное ООП без недостатков ХайАсма Но пока все слишком размыто и трудно представимо именно в графической форме ... (Как представить универсальный механизм записи классов в потоки как показать наследование или универсальные коллекции? ) Понятно что низкоуровневый код можно просто показать как обычный алгоритм, но наглядность подобного представления крайне сомнительна ... Зы Пока есть столбовая идея "Контейнер" var - Контейнер Type - Контейнер Класс - Контейнер porocedure - Контейнер Begin end - Контейнер Все прочие операторы типа (if then else ...) имеют поля условий и/или место(или места) для одного контейнера на схеме контейнер показывается одним кубиком который можно открыть кликом мыши ... Потоков в понимании хайАсма в проекте пока нет (Но возможны надстройки ) имеется одна линия "ход исполнения" и ветвления происходят только в "глубину" через механизмы контейнеров а еще доступно "дерево премьерных" что-то вроде объектной навигации в современных ИДЕ ) Но все это спасет только на среднем уровне (уже форму представить так сложно .) |
|||
| карма: 0 |
|
|
Ответов: 1841
Рейтинг: 369
|
|||
|
AlexKir, как занесло Вас
ЛЮБОЙ_ЯВУ -> ? -> СХЕМА ? - вот тут что делать то? Даже компиляторы этих ЯП иногда ошибаются при разборе семантики, из-за чрезмерной сложности всех нюансов... |
|||
| карма: 1 |
|
Ответов: 316
Рейтинг: 21
|
|||
|
CriDos писал(а): AccessFTP(dir) //Директория элемента, в которой хранятся все необходимые файлы---------element(file) //Файл конфигурации элемента ---------script(file) //Скрипт ---------icons(dir) //Каталог с состояниями --------------main.png(file) //Состояние --------------new.ico(file) //Состояние --------------end.ico(file) //Состояние ---------lang(dir) //Каталог с переводами -------------ru(file) //Файл описания элемента -------------en(file) //Файл описания элемента -------------ar(file) //Файл описания элемента Можешь объяснить по поводу обработчиков элемента в графической среде, это папка скрипт или обработчики отдельно? Компиляторы находятся в пакете или где-то в среде? Что по поводу удаленной сборки думаешь? |
|||
| карма: 1 |
|
|
Ответов: 1841
Рейтинг: 369
|
|||
|
LastLeader писал(а): обработчиковЧто подразумевается под обработчиком в данном случае? LastLeader писал(а): Компиляторы находятся в пакете или где-то в среде?Локальные компиляторы, скорее всего, будут так-же находиться в папке compilers. LastLeader писал(а): Что по поводу удаленной сборки думаешь?Для кодогенератора, можно разработать сервер, который будет принимать трафик обёрнутый в AES 256 (или чего там) и отдавать результат. В среде, предусмотреть профили, поддерживающие удалённую сборку. Т.е. по сути, можно будет собрать схему, без файлов скриптов и инструментов сборки. Они будут находиться на стороне сервера. |
|||
| карма: 1 |
|
|
Ответов: 316
Рейтинг: 21
|
|||
|
CriDos писал(а): Что подразумевается под обработчиком в данном случае? Обработчик событий в графической среде, например мы подводим мышку к элементу на рабочем поле и хотим чтоб он изменил иконку или если изменился параметр одного элемента то скрыть другие параметры или даже некоторые элементы на панели элементов. (обработчик позволяет управлять граф. средой, аналогияно жаваскрипта в html) Этот термин (обработчик событий ) ввел -Netspirit, я раньше их называл скриптами))) |
|||
| карма: 1 |
|
|
Ответов: 964
Рейтинг: 12
|
|||
|
AlexKir, как занесло Вас
ЛЮБОЙ_ЯВУ -> ? -> СХЕМА ? - вот тут что делать то? Даже компиляторы этих ЯП иногда ошибаются при разборе семантики, из-за чрезмерной сложности всех нюансов...
Так пусть себе ошибаются ... Но компиляторы . Чем хорош хайасм ? Разумеется работой на высоком и немного на среднем уровне .. А с низ и часть середины взвываю ''муки творчества '' там где достаточно нескольких строк . на обычном яву . Вот я и хочу добавить возможность легкого перехода от схемы к коду и обратно Более того добавить возможность ПРЯМО в СХЕМЕ делать вставки на яву без возни с инлайном или элементами (Разумеется при должном навыке добавить инлайн не сложно однако '' камерность'' и слишком четкая ''грань' и множество лишних движений (сложный дjоступ к данным обязательный модуль и класс на каждый чих ) часто съедают все плюсы в подобного решения ) Я прекрасно понимаю почему так сделано . Есть готовый механизм создания элементов его чуть модифицировали и ''маемо то что маемо'' .... Превращение внешнего но ''рабочего кода'' в ''сырую схему'' у меня сводится к расстановке комментариев и разбивании кода на секции . Возможно даже через ''сакраментальное инклуде''. Первично на с схеме будет что наподобие ''зигзага удачи'' Но что мешает навести красоты в визуальной форме? (Вероятно будет и распознавание элементов среднего и высокого уровня например формы и прочие визуальные элементы ) Поэтому у меня в любой момент можно и посмотреть ''перевод'' в код и сделать вставку кода прямо в схеме Обратный процесс СХЕМА ->КОД будет еще проще ... А схемы рисуемые непосредственно в редактор будут содержать и элементы значительно более высокого уровня .. Это могут быть не только обычные элементы визуального программирования но и блоки управления/ БД или описания поведения трехмерных объектов разные инструменты продержки ГИС или веб-интерфейсы ... |
|||
| карма: 0 |
|
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
|
LastLeader писал(а): Этот термин (обработчик событий ) ввел -NetspiritЭто, просто, он отлично его перенял. Но, увы, первенство принадлежит не ему. Но я, как бы, совсем не против |
|||
| карма: 22 |
|
|
Ответов: 1841
Рейтинг: 369
|
|||
|
LastLeader писал(а): например мы подводим мышку к элементу на рабочем поле и хотим чтоб он изменил иконку или если изменился параметр одного элемента то скрыть другие параметры или даже некоторые элементы на панели элементов.В таком случае, лучше делать это не из скрипта элемента, в котором будет находиться функциональная реализация элемента, а конфигурационном. Т.е. по сути, у нас будет обычный "шаблонный" файл с конфигурацией элемента (как сейчас) и, если требуется, скрипт (обработчик ), у которого будут возможности реагировать на события в реальном времени и взаимодействовать через API со средой.Тут мне очень понравилась система сигналовслотов в Qt. Таким образом, мы отделяем функциональную часть, которая может находиться только на сервере, от графической, которая будет находиться на стороне клиента. |
|||
| карма: 1 |
|
|
Ответов: 316
Рейтинг: 21
|
|||
|
CriDos писал(а): Тут мне очень понравилась система сигналовслотов в Qt.Эти слова клосплатформенны? Нужно ж будет и в Hion это реализовывать. |
|||
| карма: 1 |
|
|
Ответов: 1841
Рейтинг: 369
|
|||
|
LastLeader писал(а): Эти слова клосплатформенны?Windows, Linux, MacOS, Android, iOS, Windows Phone - web'а нету пока А вообще, довольно сложно будет реализовать всё это в вэбе... Легче будет разбить графическую часть на составляющие, используя модель-представление-поведение (как у меня). Далее, на серверной стороне использовать серверное приложение со своим API, которое будет манипулировать только моделью, а представление уже реализовать в вебе (js, flash и тд). Т.е. в hion мы передвинули кубик, эта информация через локальный\внешний API передаётся приложению, приложение всё считает и выдаёт представление, которое мы уже отображаем любыми средствами  В общем, получаем маленькую онлайн игру (по сложности), но с кубиками |
|||
| карма: 1 |
|
Поиск
Друзья
Администрация