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