Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Решение хорошее, опробовал сегодня и на яблоке, и на андроиде. Везде свои плюсы и минусы, но думаю они решаемые. Вот чего, конечно, не хватает - это федерации. Развернуть локальный сервер нынче имеет смысл, который сложно переоценить, но без возможности общения с другими островами - он по факту бесполезен. Потому что изолированный корп.чат можно сделать сейчас на каком угодно открытом \ коммерческом решении, но почти никто не предлагает федерацию, кроме пожалуй Matrix / Element.
Да есть оплата. Сам сидел продолжительное время. Здесь скорее речь о том, что провайдер, принимающий оплату из РФ, для Европы как красная тряпка для быка. А если это оплата через зарубежные способы, то вроде норм.
Судя по моим изысканиям в последние пару дней, щас впринципе арендовать vds в Европе с оплатой в рублях нереально. Скорее всего по причинам указанным в статье.
Ну если в расширении творить дичь и не обкладывать это тестами / документацией и вообще херню творить, то конечно оно дороже выходит.
Мы по своему опыту сокращаем издержки обновления с вынесением доработок через расширения примерно в 3 раза, за счет использования программных изменений форм, гита, diffmerge для быстрого изменения захваченных модулей и сравнения с изменениями в типовых.
Для себя вывели несколько приложений в веб на 1С:Элемент: платежи, внутренний учет задач, корпоративный портал, несколько доп.сервисов для обмена данными. По сути получилась аналогичная схема как у вас, только бекенд и фронт у нас идет в виде единого приложения, которое пишется теми же 1С-никами, которые дорабатывают и учетные системы на платформе. Особенно круто это работает на мобилках, так как сейчас это основной вид интерфейса для руководства. Обмен по HTTP, который делается в самом веб-приложении, то есть учетные системы так и остаются за NATом в защите. В последнее время экспериментирую с переходом на реалтайм обмен через 1С:Шину (брокера сообщений по сути), у которого есть нормальная поддержка что в платформе, что в Элементе.
А за in-frame режим отдельное спасибо. Долгое время пытался понять как 1С в своем решении Бизкуб засунули отображение приложения на 1С внутри приложения на 1С:Элемент, теперь понял.
Вы сейчас по сути описали работу технологии 1С:Элемент, который по факту - веб-приложение на реакте с java-бекендом, при этом все реализовано в привычной для 1С-ника парадигме проектирования с множеством синтаксического сахара, компонентности, переиспользуемость и всего того, чего так не хватает в самой платформе. Да, и интерфейс там даже чуть приятнее чем в 8.5 (речь про типовой формат), но при этом никто не запрещает сделать сколь угодно сложный и красивый интерфейс. Мы вот у себя такого рода вещи делаем на Элементе как раз, с обменом по REST \ кролику с основной учетной системой 1С. Причем никаких веб-разработчиков, все силами 1С-ников.
1С:Касса. Там еще есть 1С:РМК, но это больше именно как чистый фронт, который должен подключаться к какой-либо бек системе: Кассе, Торговле, Бухгалтерии, УНФ и т.д. Детали на официальном сайте 1С можно посмотреть.
В библиотеке стандартных подсистем есть же механизм обновления конфигурации через интернет. Вот ее можно использовать для облачного обновления и установки, только не с серверов 1С (хотя можно и их), а со своего. С расширениями еще проще, они сами себя в целом умеют обновлять, по аналогии с самообновлением конфигурации. Вот и пожалуйста, централизованное распространение единой версии ПО. А данные через опять же БСП-шный механизм EnterpriseData по HTTP (точнее SOAP). Все уже придумано за нас, это надо только организовать и настроить.
Тем более что у 1С есть полноценное оффлайн приложение, которое обменивается только итоговыми данными по ценам, выручке, номенклатуре и прочая. Там даже чеки не передаются, ибо незачем, отчет о розничных продажах закрывает потребность. Но если очень надо - можно и их.
Просто мало кто действительно хочет в ритейле заниматься поддержкой всех 50 баз отдельно, каждая свою, вот и придумывают то риб, то облачное размещение. Сам сопровождаю одну такую розничную сеть, которая наотрез отказалась от использования оффлайн приложения на точках по вышеозначенным причинам + еще нескольким внутренним.
Специально для разработчиков, которые не любят устоявшуюся парадигму языка 1С, и был выпущен язык 1С:Элемент, который java-подобный (потому что бекенд на java сделан и синтаксис явно взят оттуда) веб ориентированный (потому что транслируется в react js) язык с поддержкой части возможностей ООП (наследования нет, но есть интерфейсы), синтаксическим сахаром а-ля свежие версии java / python и множеством внутренних улучшений. Насчет подключаемых модулей на java - пока ждем, но запрос к разработчикам фреймворка есть. И да, эффект получается такой же как при появлении 8.0 в бытность 7.7 как основной платформы и технологии.
В 8.3 вырвиглазный желтушный цвет. В 8.5 ранних сборках очень криво отрисовывался интерфейс, сильно перегруженный. В свежих 8.5 уже выглядит намного лучше, но опять же - жесткие рамки интерфейса и возможностей. В Элементе за счет переиспользуемости компонент и большого набора базовых элементов можно собрать какие угодно доп компоненты, которые отсутствуют в стандартной поставке. А если и их не хватает - что ж, HTML + CSS никто не отменял.
Не стоит. Я разрабатываю на 1С чуть больше 10 лет, стремясь использовать в своих проектах самые современные фишки и интерфейсы 1С. И писать решение с нуля - это самое худшее решение. Писать решение на базе стандартных библиотек 1С - лучше, но тоже так себе.
И полтора года пишу на Элементе, где нет вообще ничего кроме двух демок, документации и комьюнити. Там можно развиваться сколько угодно, и этот язык и Фреймворк я считаю более перспективным, нежели современную платформу 1С. В основном из-за малого легаси кода и библиотечного подхода к разработке, что кратно сокращает процесс разработки новых решений. Жаль только пока комьюнити небольшое, библиотек готовых мало (7 от 1С, с десяток от опенсорс сообщества)
Говорят, если начинаешь писать конфигурацию с нуля, с правильной архитектурой, с бизнес логикой продуманной, с адекватными и удобными интерфейсами, то Фреймворк 1С раскрывается с совершенно другой стороны... Пока не взвоешь от реального количества кода, который надо придумать и реализовать.
Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Решение хорошее, опробовал сегодня и на яблоке, и на андроиде. Везде свои плюсы и минусы, но думаю они решаемые. Вот чего, конечно, не хватает - это федерации. Развернуть локальный сервер нынче имеет смысл, который сложно переоценить, но без возможности общения с другими островами - он по факту бесполезен. Потому что изолированный корп.чат можно сделать сейчас на каком угодно открытом \ коммерческом решении, но почти никто не предлагает федерацию, кроме пожалуй Matrix / Element.
Адептус-меканикус: Начало
Да есть оплата. Сам сидел продолжительное время. Здесь скорее речь о том, что провайдер, принимающий оплату из РФ, для Европы как красная тряпка для быка. А если это оплата через зарубежные способы, то вроде норм.
Судя по моим изысканиям в последние пару дней, щас впринципе арендовать vds в Европе с оплатой в рублях нереально. Скорее всего по причинам указанным в статье.
Казахстан и Беларусь доступны, пока...
Москва. Билайн проводной. Сервисы московские открывается, из СПб - нет. Внешний канал работает.
На мобильной сети того же Билайна все работает без проблем и трех букв.
Ну если в расширении творить дичь и не обкладывать это тестами / документацией и вообще херню творить, то конечно оно дороже выходит.
Мы по своему опыту сокращаем издержки обновления с вынесением доработок через расширения примерно в 3 раза, за счет использования программных изменений форм, гита, diffmerge для быстрого изменения захваченных модулей и сравнения с изменениями в типовых.
Для себя вывели несколько приложений в веб на 1С:Элемент: платежи, внутренний учет задач, корпоративный портал, несколько доп.сервисов для обмена данными. По сути получилась аналогичная схема как у вас, только бекенд и фронт у нас идет в виде единого приложения, которое пишется теми же 1С-никами, которые дорабатывают и учетные системы на платформе. Особенно круто это работает на мобилках, так как сейчас это основной вид интерфейса для руководства. Обмен по HTTP, который делается в самом веб-приложении, то есть учетные системы так и остаются за NATом в защите. В последнее время экспериментирую с переходом на реалтайм обмен через 1С:Шину (брокера сообщений по сути), у которого есть нормальная поддержка что в платформе, что в Элементе.
А за in-frame режим отдельное спасибо. Долгое время пытался понять как 1С в своем решении Бизкуб засунули отображение приложения на 1С внутри приложения на 1С:Элемент, теперь понял.
Вы сейчас по сути описали работу технологии 1С:Элемент, который по факту - веб-приложение на реакте с java-бекендом, при этом все реализовано в привычной для 1С-ника парадигме проектирования с множеством синтаксического сахара, компонентности, переиспользуемость и всего того, чего так не хватает в самой платформе. Да, и интерфейс там даже чуть приятнее чем в 8.5 (речь про типовой формат), но при этом никто не запрещает сделать сколь угодно сложный и красивый интерфейс.
Мы вот у себя такого рода вещи делаем на Элементе как раз, с обменом по REST \ кролику с основной учетной системой 1С. Причем никаких веб-разработчиков, все силами 1С-ников.
1С:Касса. Там еще есть 1С:РМК, но это больше именно как чистый фронт, который должен подключаться к какой-либо бек системе: Кассе, Торговле, Бухгалтерии, УНФ и т.д. Детали на официальном сайте 1С можно посмотреть.
В библиотеке стандартных подсистем есть же механизм обновления конфигурации через интернет. Вот ее можно использовать для облачного обновления и установки, только не с серверов 1С (хотя можно и их), а со своего. С расширениями еще проще, они сами себя в целом умеют обновлять, по аналогии с самообновлением конфигурации. Вот и пожалуйста, централизованное распространение единой версии ПО. А данные через опять же БСП-шный механизм EnterpriseData по HTTP (точнее SOAP). Все уже придумано за нас, это надо только организовать и настроить.
РИБ в целом зло, которое нужно убить.
Тем более что у 1С есть полноценное оффлайн приложение, которое обменивается только итоговыми данными по ценам, выручке, номенклатуре и прочая. Там даже чеки не передаются, ибо незачем, отчет о розничных продажах закрывает потребность. Но если очень надо - можно и их.
Просто мало кто действительно хочет в ритейле заниматься поддержкой всех 50 баз отдельно, каждая свою, вот и придумывают то риб, то облачное размещение. Сам сопровождаю одну такую розничную сеть, которая наотрез отказалась от использования оффлайн приложения на точках по вышеозначенным причинам + еще нескольким внутренним.
Специально для разработчиков, которые не любят устоявшуюся парадигму языка 1С, и был выпущен язык 1С:Элемент, который java-подобный (потому что бекенд на java сделан и синтаксис явно взят оттуда) веб ориентированный (потому что транслируется в react js) язык с поддержкой части возможностей ООП (наследования нет, но есть интерфейсы), синтаксическим сахаром а-ля свежие версии java / python и множеством внутренних улучшений. Насчет подключаемых модулей на java - пока ждем, но запрос к разработчикам фреймворка есть. И да, эффект получается такой же как при появлении 8.0 в бытность 7.7 как основной платформы и технологии.
В 8.3 вырвиглазный желтушный цвет. В 8.5 ранних сборках очень криво отрисовывался интерфейс, сильно перегруженный. В свежих 8.5 уже выглядит намного лучше, но опять же - жесткие рамки интерфейса и возможностей. В Элементе за счет переиспользуемости компонент и большого набора базовых элементов можно собрать какие угодно доп компоненты, которые отсутствуют в стандартной поставке. А если и их не хватает - что ж, HTML + CSS никто не отменял.
Не стоит. Я разрабатываю на 1С чуть больше 10 лет, стремясь использовать в своих проектах самые современные фишки и интерфейсы 1С. И писать решение с нуля - это самое худшее решение. Писать решение на базе стандартных библиотек 1С - лучше, но тоже так себе.
И полтора года пишу на Элементе, где нет вообще ничего кроме двух демок, документации и комьюнити. Там можно развиваться сколько угодно, и этот язык и Фреймворк я считаю более перспективным, нежели современную платформу 1С. В основном из-за малого легаси кода и библиотечного подхода к разработке, что кратно сокращает процесс разработки новых решений. Жаль только пока комьюнити небольшое, библиотек готовых мало (7 от 1С, с десяток от опенсорс сообщества)
Говорят, если начинаешь писать конфигурацию с нуля, с правильной архитектурой, с бизнес логикой продуманной, с адекватными и удобными интерфейсами, то Фреймворк 1С раскрывается с совершенно другой стороны... Пока не взвоешь от реального количества кода, который надо придумать и реализовать.
Итог - заработать в найме именно на дизайне миллион - нереально. Потому что когда ты руководишь - ты не занимаешься дизайном
Ответ на поверхности - конструктор запроса автоматом меняет ISNULL на ЕСТЬNULL. Потому и не отображается. Но использовать конструкцию можно.
Открою секрет. В запросах можно вводить ISNULL, запрос будет валидный в любом написании