=)))
gosuslugi.ru в данный момент: «По техническим причинам с 12:00 02 апреля по настоящее время недоступен сервис проверки номера СНИЛС. Рекомендуем Вам не начинать процедуру регистрации до момента устранения технических проблем. „
Так что ни авторизоваться, ни зарегистрироваться.
Я просто сам разработчик ПО, которое в том числе подпадает под модель СААС. Часто гляжу на попытки компаний российских типа 1с-Битрикс. А так же сам выступаю как клиент подобных решений.
Пока что чаша весов у СААС решений не дотягивала до нужной позиции в моей деятельности.
В России, как мне кажется, все-таки сформирован такой принцип полагаться только на себя, на свои силы. Потому что недоверие, воровство, обман, взятки и много-много чего другого. Поставщику услуги удобно привязать клиента к себе. Клиенту же удобно иметь все свое стационарное.
Вероятно, с увеличением скорости рынка, скорости появления инноваций менталитет изменится. Люди поймут, что тратить время надо не на смежные сервисы, которыми ты себя обставляешь, а на свою главную задачу, свой продукт, т.е. они будут арендовать вспомогательные услуги.
Задача ведь не сделать так, как хочет пользователь. Сколько людей — столько и мнений. Задача — сделать нормальную возможность ПОЛУЧИТЬ итоговую сумму с оформленной формой. Надо просто решиться и выбрать, как это преподнести клиенту. Чем у клиента больше возможностей, тем сложнее выбор. Должна быть одна форма. Все.
Система ведь для того и нужна, чтобы оперативно вносить новые данные или изменять старые. Если по каким-то причинам продажи не пойдут и причиной этому будет форма, ее можно оперативно поменять. Для этого система предлагает все условия.
Спорить можно долго. Мы реализовали то, что, как нам кажется, достаточно и при этом не усложняет систему настолько, чтобы писать толмуды документации. Возможен вариант иного развития событий.
Весь продукт сделан на CMF Mozart, который, в общем, крутится на всех этих W3C технологиях. Когда-то у нас в API даже были средства по работе с Xforms, но они не прижились. Т.е. они были псевдо элементами, поскольку браузеры все это не поддерживали и весь процессинг приосходил на сервере. Это долгая история, но сейчас, глядя на развитие различных стандартов, включая HTML5, я бы сказал уже, что у XForms нет особого будущего. В общем, мы от них отказались в самой системе и особо не рассматривали в Insurance как продукте, потому что все-таки задачи хоть и схожие, но хотелось иметь что-то специфическое, конкретное под нашу задачу, а не униврсальное, и потому со своими причудами типа XForms.
Пример, озвученный вами, решается ведь просто: разместите сумму в начале списка (пусть это будет диапазон), а все остальные поля поставьте в зависимость от этой суммы. =) Разве это не решение?.. Мы ведь делали свой продукт не на основе какой-то теории, был вполне реальный пример с довольным большим списком практических страховых продуктов. И под все их них возможности Insurance подошли. Хотя изначально вопрос о линейности стоял, но практического применения иного алгоритма просто не смогли найти.
Вообще, если это интересно, то имеется демо-сайт, где можно увидеть разные варианты калькуляторов и полазить внутри, посмотреть, как они сделаны. Могу выслать в личку.
В CONTROLLER мы описали требования к полям, во VIEW их внешний вид на странице.
Что касается вопроса линейности зависимостей, то она линейна, т.е. нет ветвлений (ну в прямом понимании этого слова, безусловно, есть такие понятия, как участвует поле в форме или нет в зависимости от ранее указанных значений, но это уже другая тема). На практике это означает, что клиент сначала указывает поле А, а только потом уже может произойти обработка логики Б, которое от него зависит. Вопрос про «сначала В, а потом А» не понял, т.к. не смог представить это на практике.
Придумали API, который описывается в виде XML. Вполне ограниченный набор полей, типов, действий и т.п. Он небольшой и описывает достаточно большой набор вариантов как полей, так и действий с ними. Т.е. текстовое поле, длина такая-то, может содержать такие-то символы, минимальная длина такая-то и все в таком духе.
Потом это уже все автоматически процессится и получается на выходе уже визуальное представление в виде html/css/js — бэкэндная поддержка на сервере. Представление в общем виде легко меняется через CSS, но в частности конкретно под какой-то проект можно и его скелет поменять, это просто связка html+xslt.
Никто не вытаскивает монстра. Продукт используется компанией уже больше 10 лет, развивается, оптимизируется. На нем реализовано много сервисов, сайтов.
Мы думали о внедрении XQuery, но не увидели смысла в этом: в системе уже есть XSLT, что принес бы нам XQuery?..
Приведенные примеры в тексте — это не модификация XML, это выборка данных из БД.
Могу упомянуть о многоуровневом кэшировании, а также SAX. В целом, все достаточно шустро, если только разработчик не пытается отпроцессить огромные портянки XML-данных через XSLT, когда для его задачи есть другие более эффективные способы решения.
Полгода назад поставил счетчики. Как житель района Зюзино Москвы отправляю каждый месяц в конце показания счетчиком на zuzino@guis-uzao.ru.
Никаких тут личных кабинетов и прочего.
Вообще, вариантов отправки данных показаний существует несколько.
gosuslugi.ru в данный момент: «По техническим причинам с 12:00 02 апреля по настоящее время недоступен сервис проверки номера СНИЛС. Рекомендуем Вам не начинать процедуру регистрации до момента устранения технических проблем. „
Так что ни авторизоваться, ни зарегистрироваться.
Дальше некуда.
Пока что чаша весов у СААС решений не дотягивала до нужной позиции в моей деятельности.
Вероятно, с увеличением скорости рынка, скорости появления инноваций менталитет изменится. Люди поймут, что тратить время надо не на смежные сервисы, которыми ты себя обставляешь, а на свою главную задачу, свой продукт, т.е. они будут арендовать вспомогательные услуги.
Спасибо за идею.
Система ведь для того и нужна, чтобы оперативно вносить новые данные или изменять старые. Если по каким-то причинам продажи не пойдут и причиной этому будет форма, ее можно оперативно поменять. Для этого система предлагает все условия.
Спорить можно долго. Мы реализовали то, что, как нам кажется, достаточно и при этом не усложняет систему настолько, чтобы писать толмуды документации. Возможен вариант иного развития событий.
Пример, озвученный вами, решается ведь просто: разместите сумму в начале списка (пусть это будет диапазон), а все остальные поля поставьте в зависимость от этой суммы. =) Разве это не решение?.. Мы ведь делали свой продукт не на основе какой-то теории, был вполне реальный пример с довольным большим списком практических страховых продуктов. И под все их них возможности Insurance подошли. Хотя изначально вопрос о линейности стоял, но практического применения иного алгоритма просто не смогли найти.
В CONTROLLER мы описали требования к полям, во VIEW их внешний вид на странице.
Что касается вопроса линейности зависимостей, то она линейна, т.е. нет ветвлений (ну в прямом понимании этого слова, безусловно, есть такие понятия, как участвует поле в форме или нет в зависимости от ранее указанных значений, но это уже другая тема). На практике это означает, что клиент сначала указывает поле А, а только потом уже может произойти обработка логики Б, которое от него зависит. Вопрос про «сначала В, а потом А» не понял, т.к. не смог представить это на практике.
Потом это уже все автоматически процессится и получается на выходе уже визуальное представление в виде html/css/js — бэкэндная поддержка на сервере. Представление в общем виде легко меняется через CSS, но в частности конкретно под какой-то проект можно и его скелет поменять, это просто связка html+xslt.
Мы думали о внедрении XQuery, но не увидели смысла в этом: в системе уже есть XSLT, что принес бы нам XQuery?..
Приведенные примеры в тексте — это не модификация XML, это выборка данных из БД.
Никаких тут личных кабинетов и прочего.
Вообще, вариантов отправки данных показаний существует несколько.