В моём опыте не было таких, кто использовал кастомные шеллы на юниксе просто потому, что кому-то не нравится синтаксис шелловского языка для написания скриптов. Все мирились и использовали shell script. Точно так же будет и тут, если тема JsOS зайдёт, большинство смирится и будет использовать то, что успешно работает "из коробки".
Но коли скрипты здесь можно писать, используя "eval-режим", проблема псевдо-языков для скриптинга вроде пропадает. Но опять таки, почему бы с самого начала полёта не убрать непривычный для JS синтаксис в шелле типа (#/*JS code*/), если эта ОС стремится быть такой JavaScript (стремится же?). То есть сделать шелл в точности таким, каким мы его видим в NodeJS или Developer Tools.
Тема с JavaScript OS крутая, но как же я ожидал что терминальный доступ придумают сделать в нотации JavaScript, а не в какой-то другой, например самостоятельно придуманной. Идеально — полноценный JavaScript shell. То есть, например, не start screenfetch, а start.screenfetch().
1. Есть ли возможность сделать какие-либо ограничивающие правила, кроме OBJPERMISSIONS, которые бы не позволили клиентам сделать «слишком много» на сервере? Например, какой-то декларативный механизм, чтобы каждый клиент мог редактировать только свойPackage.Test.Client. Пока что выглядит так, что для такой цели нужно писать свой REST endpoint. Или это уже beyond the scope of RESTForms?
2. При успешном создании объекта RESTForms возвращает {"Id": "101"}. Всё время спрашиваю себя, почему не {"_id": "101"}?
HTTP/2 server push — это не просто дополнительные заголовки. Nginx должен разбирать заголовки ответа и отправлять «проталкиваемые» ресурсы в ответ на запрос клиента.
Я не могу посетить многие из этих сайтов, потому что они заблокированы в uBlock Origin
Но ведь эту кнопку так старались сделать заметной…
Картинка
У меня есть знакомый, который похожими методами, только через VK API сделал дизайнерский сайт для паблика вконтакте. В паблике публикуются новости и фотографии, а на сайте они сами поттягиваются и отображаются через всякие красивые галлереи. Так что метод рабочий, но свой сервер завести всё равно лучше.
Хм. Да, в таком случае только вручную удалять, или писать свой код для очистки области от классов, которых нет в исходниках. Лично в моей практике удаление классов ещё не встречалось.
В каких-то случаях может и имеет смысл написать скрипт, который бы из, например, истории Git'а вытягивал бы список удалённых классов, и удалял их из СУБД, но думаю более элегантным и простым решением будет удаление отсутствующих при сборке проекта классов в пределах определённого пакета или области.
Инструмент ещё не готов до конца — его разработка была временно приостановлена, но пользоваться уже можно, установка в один импорт. Очень хорошо применяется в образовательных целях или «быстро что-то поправить», почти полноценный веб-редактор, можно код писать. Адаптирован в том числе и под мобильные платформы. В перспективе сделать ещё экраны редактора хранимых данных и конфигурации.
Пробовал и я эту штуку. Как незначительное отличие, можно отметить, что предоставленный способ в статье не требует импорта каких-либо классов в Caché перед работой. Вариантов много! Любопытно узнавать, как кто разрабатывает.
Каждый оценивает сам как и где ему удобнее. Данный способ не привязан к конкретной IDE — в статье как пример упомянута работа в Intellij IDEA, описаны преимущества и недостатки такого подхода. Другое дело, подход не привычный для стека технологий InterSystems, потому может и непонятно. Например, я свои проекты (1, 2) уже около полугода разрабатываю этим способом, собираю фронтенд/бекенд одной кнопкой и студию вообще не открываю. После ~2,5 лет разработки в студии я нашёл такой подход для себя гораздо более удобным. Попробуйте — может, найдёте и вы.
Принципиальное отличие в том, что представленный подход основан на файлах и прямой работе с ними. Например, это позволяет использовать любые «внешние» инструменты для их процессинга, писать код в любом редакторе и так далее.
Что касается Atelier, доступна Field Test версия. Ссылку добавлю в статью, спасибо.
Это нереально полезно открывать во время установки окно браузера с настройками приложения. Если знает кто код такой, и это правда возможно, было бы любопытно узнать как.
Исследовал как-то, что read в случае с проекциями, к сожалению, не работает. Так что чуть ли не единственным вариантом остаётся просить пользователя задавать какой-то глобал перед установкой. А при отсутствии глобалов устанавливать приложение "по-умолчанию", что, в принципе, для большинства пользователей подходит.
Само обновление (процесс загрузки классов из сети) — да. Нужно дополнительно написать код, который будет заниматься обновлением: скачает и импортирует XML (или *.cls с 2016.1) файлы. Проекции — это всего лишь возможность выполнить что-то во время компиляции.
В целом, с данным способом поставки всё сводится к написанию небольшого модуля, который занимается проверкой обновлений, и который будет скачивать, импортировать и компилировать новые классы. И в данном случае все необходимые настройки сделает уже новый импортированный Installer.
Вот небольшая сводка того, что уже есть по этой теме на сегодня:
В Caché WEB Terminal, при выполнении команды /update, на сервере вызывается метод Update. Он загружает из сети XML указанной версии, а затем импортирует и компилирует загруженные классы;
В проекте DeepSeeWeb так же есть метод, загружающий XML последнего релиза с GitHub;
Есть утилита для continuous-обновления приложений напрямую из репозитория, если там хранятся XML — GitHubUpdater.
На Apache можно разместить только клиентское приложение (или даже воспользоваться уже готовым онлайн-клиентом). В случае с Apache (если вы имеете в виду именно чистый веб-сервер, без PHP там всяких) это станет самым подходящим для Вас вариантом. Но серверная часть написанного мной приложения всё равно требует Node.JS, тут без нового кода не обойтись.
Приятно узнавать, что вам понравилось, спасибо! Интерфейс был написан «вручную» на чистом JavaScript, HTML и CSS, а бэкенд на NodeJS. Тогда, как и сейчас, во многих креативных случаях я не предпочитаю использовать какие-либо графические фреймворки.
В моём опыте не было таких, кто использовал кастомные шеллы на юниксе просто потому, что кому-то не нравится синтаксис шелловского языка для написания скриптов. Все мирились и использовали shell script. Точно так же будет и тут, если тема JsOS зайдёт, большинство смирится и будет использовать то, что успешно работает "из коробки".
Но коли скрипты здесь можно писать, используя "eval-режим", проблема псевдо-языков для скриптинга вроде пропадает. Но опять таки, почему бы с самого начала полёта не убрать непривычный для JS синтаксис в шелле типа
(#/*JS code*/), если эта ОС стремится быть такой JavaScript (стремится же?). То есть сделать шелл в точности таким, каким мы его видим в NodeJS или Developer Tools.Тема с JavaScript OS крутая, но как же я ожидал что терминальный доступ придумают сделать в нотации JavaScript, а не в какой-то другой, например самостоятельно придуманной. Идеально — полноценный JavaScript shell. То есть, например, не
start screenfetch, аstart.screenfetch().1. Есть ли возможность сделать какие-либо ограничивающие правила, кроме
OBJPERMISSIONS, которые бы не позволили клиентам сделать «слишком много» на сервере? Например, какой-то декларативный механизм, чтобы каждый клиент мог редактировать только свойPackage.Test.Client. Пока что выглядит так, что для такой цели нужно писать свой REST endpoint. Или это уже beyond the scope of RESTForms?2. При успешном создании объекта RESTForms возвращает
{"Id": "101"}. Всё время спрашиваю себя, почему не{"_id": "101"}?Спасибо!
У меня есть знакомый, который похожими методами, только через VK API сделал дизайнерский сайт для паблика вконтакте. В паблике публикуются новости и фотографии, а на сайте они сами поттягиваются и отображаются через всякие красивые галлереи. Так что метод рабочий, но свой сервер завести всё равно лучше.
В каких-то случаях может и имеет смысл написать скрипт, который бы из, например, истории Git'а вытягивал бы список удалённых классов, и удалял их из СУБД, но думаю более элегантным и простым решением будет удаление отсутствующих при сборке проекта классов в пределах определённого пакета или области.
Что касается Atelier, доступна Field Test версия. Ссылку добавлю в статью, спасибо.
В целом, с данным способом поставки всё сводится к написанию небольшого модуля, который занимается проверкой обновлений, и который будет скачивать, импортировать и компилировать новые классы. И в данном случае все необходимые настройки сделает уже новый импортированный Installer.
Вот небольшая сводка того, что уже есть по этой теме на сегодня:
С удовольствием слежу за вашим каналом. Так держать!