Та же непонятная пиктограмма настройки после нажатия на кнопку смены темы. И только со второго нажатия тема меняется.
Это не пиктограмма настройки, это пиктограмма светлой темы - солнце. А переключатель там: светлая тема (солнце) - темная тема (месяц) - системная тема. Возможно, не совсем очевидно, соглашусь, но обычно это переключение происходит один раз (или ноль).
Второй появился не так давно, оказался нужен людям (в том числе и каким-то нашим собственным решениям), которые сначала пишут решение с использованием своего родного языка для локального рынка и им видеть "живые" строки удобнее, а потом у них появляется необходимость в мультиязычности. Такой подход может помочь довольно быстро какую-то первичную мультиязычность получить. На самом деле, мы будем, конечно, улучшать весь функционал мультиязычности в недалеком будущем.
И не увидел у вас — как вы подставляете параметры в серидину строки
Если в контексте локализации, то для lsf кода, насколько я знаю, сейчас пока что никак, из java-кода такая возможность есть, но java — это, конечно, редкое явление в решениях. То есть в составном тексте кусочки пока что локализуются по отдельности. Есть функциональность, которая решает совсем другую задачу. Литерал может включать в себя множество идентификаторов: '{id1} = 10 {id2}'.
Если не в контексте локализации, то строчки сейчас в основном формируют с помощью CONCAT. Не помню, есть ли у нас в ближайших задачах появление какого-нибудь условного FORMAT c форматной строкой, но не помешало бы добавить что-нибудь в идеале похожее на f-strings в python.
Я, честно говоря, в контексте логических зависимостей не вижу большой разницы между задачами, которые решаются с помощью платформы, и произвольными сложными задачами вообще. С зависимостями борются везде. И способов для этого придумали уже довольно много. Одни и те же бизнес-задачи, реализованные в коде, могут иметь совершенно разное количество связей и это зависит в том числе и от того, какой инструмент у вас под рукой.
Более того, я вижу как в наших решениях реализуется довольно много вещей, которые вообще мало от чего зависят: это и интеграции с какими-то внешними системами, интеграции с оборудованием, и какие-то отчеты, и какие-то постоянные дополнительные пожелания клиентов, которые выносятся в отдельные модули. В наших решениях вполне нормально используется модульность, предоставляемая платформой.
Так же интересует — что у вас с мультиязычной поддержкой? Я понял, что вы выносите все в ресурсы, но некоторые вещи меня заставляют окунаться прям в мир типовых. А именно — тут ошибка в ключе? Или это фича.
Это просто github так отображает, там нет ошибки в ключе. Вообще в Intellij будет отображаться нормальная кириллица, если включить опцию в File Encodings
А тут почему написан текст харкодом? Та и не только тут, а прям по всей системе. Это фича?
У нас сейчас реализовано два подхода к интернационализации. Первый — это идентификаторы в строковых литералах. Второй — когда все строковые литералы пишутся на каком-то языке, а механизм обратной интернационализации уже сам находит нужный идентификатор в ресурсных файлах. В модулях MyCompany используется, насколько я знаю, второй вариант сейчас.
Что там с документацией? Где ее почитать?
Я так понимаю, что документацию вы нашли? В основном все там плюс этот блог на хабре.
P.S. Вы вебинары делаете, или типо того, чтобы можно было лично вопросы позадавать, получить ответы и прочее.
Прямо сейчас (и в любое другое время) можно зайти к нам в слэк
Тут ведь вопрос обычно в том, насколько язык/платформа позволяют минимизировать количество связей между сущностями из разных модулей. В lsfusion для этого есть набор механизмов (расширения, subtype полиморфизм, открытые классы и т. п.), которые позволяют вам уменьшить количество таких связей.
А так то, понятно, что любая модульность может быть убита ошибками проектирования.
Нет, я пробовал на пальцах пояснить, что имелось ввиду в комментарии, на который вы ответили "Не может одна строка кода полностью заменить "километровый" запрос SQL."
Имеется ввиду, что если у вас есть уже в программе какая-то вычисляемая величина, например, "Остаток". То, например, установить ограничение на то, что этот остаток должен быть всегда неотрицательный, можно одной строкой. Независимо от того, от чего эта величина зависит. Да, там может быть в результате километровый SQL-запрос, если эта величина сложно вычисляется, но запрос будет сформирован платформой.
Еще раз, нужно понимать что lsFusion для логики вычислений использует виртуальную машину сервера БД (SQL сервер), а не виртуальную машину сервера приложений (JVM или .Net). То есть прикладных объектов нет на сервере приложений ВООБЩЕ (если не считать редких случаев, когда изменение идет ровно для одного объекта, но это уже детали). То есть NoORM, YesSQL. Соответственно никакая транспиляция не возможна в принципе.
Да, вот это вот главное препятствие для такого варианта вообще. Можно было мне свой комментарий и не писать.
Давайте. Как я предлагал, давайте сделаем надстройку над существующим языком, например, c#. Делаем препроцессор который парсит файлы fsn и делает транспиляцию в c#.
В приведенном примере вы как-то лихо предположили, что классы и свойства lsfusion хорошо лягут на классы и свойства c#. В lsfusion у классов есть множественное наследование, нет инкапсуляции (в плане "объединения данных и методов работы с ними"), классы открыты, то есть в любом месте программы их можно расширить. У свойств, например, есть multiple-dispatch, то есть subtype полиморфизм по любому подмножеству параметров. А сверху этого всего есть еще модульность и логика пространств имен. Так просто отобразить это на c# классы у вас не получится.
Если брать, например, CONSTRAINT из lsfusion, то он работает не только для каких-то первичных данных, но и для произвольного выражения, а это выражение в свою очередь может вычисляться через сотни других свойств. И объявлен этот CONSTRAINT может быть в другом модуле. Как вы будете это протаскивать в c# код?
после транспиляции у нас получается чистый c# код
Хорошо, так а писать мы в этом случае на чем будем? На вот этой надстройке ведь, которая по сути тот же DSL, для которого изначально не будет никакой поддержки IDE. Но вообще даже об этом нужно говорить только тогда, когда вы придумаете, как lsfusion на тот же c# отобразить, чтобы это имело хоть какой-то смысл, а не было просто библиотекой со своим API, как я приводил выше.
Приведенный выше пример — это как раз кусок императивного кода. Все же в lsfusion бОльшая часть кода — декларативна.
Смотрите, возвращаясь к исходной теме статьи, у lsfusion все же своя парадигма. Немного громкое слово, но мы используем его в документации. Можно назвать это концепцией. БОльшая часть кода — это по сути просто декларативное объявление неких сущностей (в терминологии lsfusion — свойств, действий, форм, классов, таблиц и т. д.).
Давайте представим, как будет выглядеть некая fluent interface реализация на каком-нибудь распространенном императивном языке (мы ведь не хотим учить новый язык). По факту получится библиотека, в которой будет куча конструирующего выше упомянутые сущности кода. В результате код, по крайней мере декларативная его часть, будет выглядеть примерно так:
Окажется, что знание языка не очень то помогает, потому что код то получается примитивный, но без знания парадигмы все равно ничего не понятно.
Что f(x) = GROUP ... в lsfusion, что f = createGroupProperty(...) в каком-нибудь языке одинаково непоняты без знания платформы. Более того, уверяю, что этот fluent interface будет довольно кривым и громоздким, а некоторые вещи возможно вообще не получится реализовать в том объеме, в котором это реализовано с DSL. Знакомый синтаксис языка оказывается вторичным. DSL же позволяет по возможности лаконично и максимально точно приблизиться к той концепции, которая им выражается. Да, императивную часть теоретически можно сделать понятней и богаче, но основная суть не в ней.
Другой вариант — это взять язык, используя возможности которого, можно попробовать добиться достаточной выразительности и функциональности, не выходя за его пределы. Но это какие языки? Lisp? Nemerle? выше вот Katahdin советовали… Но процент потенциальных пользователей платформы, которые знают что-нибудь из подобного, настолько несущественен, что не видно никакого смысла в их использовании. Конечно, это в контексте того, что для программирования на lsfusion есть среда разработки с достаточно взрослой поддержкой языка.
Я не против того что вы свои язык делаете, на здоровье. Я в том что знания этого языка никуда не конвертируются, кроме как у очень ограниченного круга его пользователей.
Да, но пользоваться платформой для разработки все равно не получится без знания ее парадигмы, а это будет примерно равносильно знанию языка. В самом языке ничего особенно волшебного нет.
Это как забивание микроскопом гвоздей. Автор выбрал неправильный инструмент для решения задачи. Язык 1с достаточно гибок, чтобы позволять «стрелять себе в ногу».
Речь же не о том. В статье сначала рассматривается объектная модель, говорится о том, что в части случаев ее использование неэффективно и нужно переходить на запросы. А дальше рассказывается о проблемах с запросами в 1С. По-моему, все вполне понятно, если прочитать статью.
Если грамотно комбинировать запросы и объектную модель, никакого избыточного чтения не будет
Ок, спасибо. В том месте статьи, которое мы сейчас обсуждаем, речь идет конкретно об объектной модели, без использования запросов. Поэтому и нет там никакой лжи.
Подождите, давайте сначала по делу, а потом уже лирику про стебарей. Вот смотрите, я практически ничего не знаю про 1С. Предлагаю для простоты разобрать первый случай:
В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается:
либо слишком много — если надо получить только одно поле (реквизит)...
Как я это понял… Идет речь об объектной модели в 1С, и речь о том, что в случае, когда мы хотим получить значение реквизита объекта, то объект будет получен из базы данных целиком, поэтому и написано «слишком много». То есть в данном конкретном случае это осуществляется не слишком эффективно. В подтверждение этих слов там приведена ссылка на сайт 1С (https://its.1c.ru/db/metod8dev#content:2754:hdoc), где написано:
Однако следует учитывать, что при обращении к ссылке считывается весь объект целиком. То, что он ранее считывался и находится в кеше, здесь не поможет, так как при работе транзакции используется отдельный кеш. Соответственно, затраты на получение одного или двух реквизитов могут оказаться неоправданно большими.
Так в чем кокретно здесь все-таки ложь? По приведенной ссылке что-то написано не так? Автор статьи как-то неправильно интерпретировал то, что там написано? Давайте конкретно, а то
«В 1С получают по одному реквизиту (не полю конечно же) все и постоянно»
Получать то получают по одному реквизиту, а сколько данных при этом из базы достается? Ведь именно это обсуждается в статье.
Хочу добавить к предыдущему ответу, что в любом случае в lsfusion никто не отбирает возможность создавать руками события и добавлять обработчики на эти события.
Это не пиктограмма настройки, это пиктограмма светлой темы - солнце. А переключатель там: светлая тема (солнце) - темная тема (месяц) - системная тема. Возможно, не совсем очевидно, соглашусь, но обычно это переключение происходит один раз (или ноль).
По-моему, автор вообще нигде не делал никаких предположений про возраст "визуальных технологий".
Речь ведь, как я понял, о MyCompany. Там количество строк посчитать несложно.
Второй появился не так давно, оказался нужен людям (в том числе и каким-то нашим собственным решениям), которые сначала пишут решение с использованием своего родного языка для локального рынка и им видеть "живые" строки удобнее, а потом у них появляется необходимость в мультиязычности. Такой подход может помочь довольно быстро какую-то первичную мультиязычность получить. На самом деле, мы будем, конечно, улучшать весь функционал мультиязычности в недалеком будущем.
Если в контексте локализации, то для lsf кода, насколько я знаю, сейчас пока что никак, из java-кода такая возможность есть, но java — это, конечно, редкое явление в решениях. То есть в составном тексте кусочки пока что локализуются по отдельности. Есть функциональность, которая решает совсем другую задачу. Литерал может включать в себя множество идентификаторов:
'{id1} = 10 {id2}'.Если не в контексте локализации, то строчки сейчас в основном формируют с помощью CONCAT. Не помню, есть ли у нас в ближайших задачах появление какого-нибудь условного FORMAT c форматной строкой, но не помешало бы добавить что-нибудь в идеале похожее на f-strings в python.
Я, честно говоря, в контексте логических зависимостей не вижу большой разницы между задачами, которые решаются с помощью платформы, и произвольными сложными задачами вообще. С зависимостями борются везде. И способов для этого придумали уже довольно много. Одни и те же бизнес-задачи, реализованные в коде, могут иметь совершенно разное количество связей и это зависит в том числе и от того, какой инструмент у вас под рукой.
Более того, я вижу как в наших решениях реализуется довольно много вещей, которые вообще мало от чего зависят: это и интеграции с какими-то внешними системами, интеграции с оборудованием, и какие-то отчеты, и какие-то постоянные дополнительные пожелания клиентов, которые выносятся в отдельные модули. В наших решениях вполне нормально используется модульность, предоставляемая платформой.
Это просто github так отображает, там нет ошибки в ключе. Вообще в Intellij будет отображаться нормальная кириллица, если включить опцию в File Encodings
У нас сейчас реализовано два подхода к интернационализации. Первый — это идентификаторы в строковых литералах. Второй — когда все строковые литералы пишутся на каком-то языке, а механизм обратной интернационализации уже сам находит нужный идентификатор в ресурсных файлах. В модулях MyCompany используется, насколько я знаю, второй вариант сейчас.
Я так понимаю, что документацию вы нашли? В основном все там плюс этот блог на хабре.
Прямо сейчас (и в любое другое время) можно зайти к нам в слэк
P. S. Извиняюсь, не в той ветке ответил
Тут ведь вопрос обычно в том, насколько язык/платформа позволяют минимизировать количество связей между сущностями из разных модулей. В lsfusion для этого есть набор механизмов (расширения, subtype полиморфизм, открытые классы и т. п.), которые позволяют вам уменьшить количество таких связей.
А так то, понятно, что любая модульность может быть убита ошибками проектирования.
Нет, я пробовал на пальцах пояснить, что имелось ввиду в комментарии, на который вы ответили "Не может одна строка кода полностью заменить "километровый" запрос SQL."
Имеется ввиду, что если у вас есть уже в программе какая-то вычисляемая величина, например, "Остаток". То, например, установить ограничение на то, что этот остаток должен быть всегда неотрицательный, можно одной строкой. Независимо от того, от чего эта величина зависит. Да, там может быть в результате километровый SQL-запрос, если эта величина сложно вычисляется, но запрос будет сформирован платформой.
В этом блоге есть уже довольно много статей с ответами на, по крайней мере, часть ваших вопросов.
А с чем идет сравнение в наших двух предыдущих статьях?
Можно попробовать здесь
Да, вот это вот главное препятствие для такого варианта вообще. Можно было мне свой комментарий и не писать.
В приведенном примере вы как-то лихо предположили, что классы и свойства lsfusion хорошо лягут на классы и свойства c#. В lsfusion у классов есть множественное наследование, нет инкапсуляции (в плане "объединения данных и методов работы с ними"), классы открыты, то есть в любом месте программы их можно расширить. У свойств, например, есть multiple-dispatch, то есть subtype полиморфизм по любому подмножеству параметров. А сверху этого всего есть еще модульность и логика пространств имен. Так просто отобразить это на c# классы у вас не получится.
Если брать, например,
CONSTRAINTиз lsfusion, то он работает не только для каких-то первичных данных, но и для произвольного выражения, а это выражение в свою очередь может вычисляться через сотни других свойств. И объявлен этотCONSTRAINTможет быть в другом модуле. Как вы будете это протаскивать в c# код?Хорошо, так а писать мы в этом случае на чем будем? На вот этой надстройке ведь, которая по сути тот же DSL, для которого изначально не будет никакой поддержки IDE. Но вообще даже об этом нужно говорить только тогда, когда вы придумаете, как lsfusion на тот же c# отобразить, чтобы это имело хоть какой-то смысл, а не было просто библиотекой со своим API, как я приводил выше.
Приведенный выше пример — это как раз кусок императивного кода. Все же в lsfusion бОльшая часть кода — декларативна.
Смотрите, возвращаясь к исходной теме статьи, у lsfusion все же своя парадигма. Немного громкое слово, но мы используем его в документации. Можно назвать это концепцией. БОльшая часть кода — это по сути просто декларативное объявление неких сущностей (в терминологии lsfusion — свойств, действий, форм, классов, таблиц и т. д.).
Давайте представим, как будет выглядеть некая fluent interface реализация на каком-нибудь распространенном императивном языке (мы ведь не хотим учить новый язык). По факту получится библиотека, в которой будет куча конструирующего выше упомянутые сущности кода. В результате код, по крайней мере декларативная его часть, будет выглядеть примерно так:
Окажется, что знание языка не очень то помогает, потому что код то получается примитивный, но без знания парадигмы все равно ничего не понятно.
Что
f(x) = GROUP ... в lsfusion, чтоf = createGroupProperty(...)в каком-нибудь языке одинаково непоняты без знания платформы. Более того, уверяю, что этот fluent interface будет довольно кривым и громоздким, а некоторые вещи возможно вообще не получится реализовать в том объеме, в котором это реализовано с DSL. Знакомый синтаксис языка оказывается вторичным. DSL же позволяет по возможности лаконично и максимально точно приблизиться к той концепции, которая им выражается. Да, императивную часть теоретически можно сделать понятней и богаче, но основная суть не в ней.Другой вариант — это взять язык, используя возможности которого, можно попробовать добиться достаточной выразительности и функциональности, не выходя за его пределы. Но это какие языки? Lisp? Nemerle? выше вот Katahdin советовали… Но процент потенциальных пользователей платформы, которые знают что-нибудь из подобного, настолько несущественен, что не видно никакого смысла в их использовании. Конечно, это в контексте того, что для программирования на lsfusion есть среда разработки с достаточно взрослой поддержкой языка.
Да, но пользоваться платформой для разработки все равно не получится без знания ее парадигмы, а это будет примерно равносильно знанию языка. В самом языке ничего особенно волшебного нет.
Ок, спасибо. В том месте статьи, которое мы сейчас обсуждаем, речь идет конкретно об объектной модели, без использования запросов. Поэтому и нет там никакой лжи.
Как я это понял… Идет речь об объектной модели в 1С, и речь о том, что в случае, когда мы хотим получить значение реквизита объекта, то объект будет получен из базы данных целиком, поэтому и написано «слишком много». То есть в данном конкретном случае это осуществляется не слишком эффективно. В подтверждение этих слов там приведена ссылка на сайт 1С (https://its.1c.ru/db/metod8dev#content:2754:hdoc), где написано: Так в чем кокретно здесь все-таки ложь? По приведенной ссылке что-то написано не так? Автор статьи как-то неправильно интерпретировал то, что там написано? Давайте конкретно, а то Получать то получают по одному реквизиту, а сколько данных при этом из базы достается? Ведь именно это обсуждается в статье.
Вы же поняли, что там речь об объектной модели? Если да, то вы можете словами всем объяснить, в чем конкретно все-таки ложь?