Круто у вас все! Статья очень интересная, спасибо!
А как вы параллелите тесты Selenium? Я в эту сторону особо не копал, у нас они выполняются в пределах 30-40 минут, ввиду их немногочисленности. Есть мысли покопать в сторону Selenium Grid.
В целом у нас считается что тесты через UI имеют наименьшую ценность. Все покрывается Unit тестами, в том числе и бизнес логика. Хотя есть целое API для быстрого написания устойчивых тестов Selenium, но менеджмент не считает это возможностью как-то упростить жизнь ручным тестеровщикам (к слову редко кто воспринимает тесты через UI всерьез, по моим наблюдениям). Может у вас есть весомый комментарий к этому, как повлиять на такое мировоззрение менеджмента?
А тесты выглядят так (мы завязываемся на серверную реализацию, и управляем UI с точки зрения более высокоуровневых объектов, таких как форма, кнопка, поле ввода, список, вкладка, окно, а не HTML элементов):
Пример кода
[Test]
public void CreateDocumentFromOperation()
{
var operationCaption = "LinkedDocDocumentOperation";
var linkedDocEntity = new EntityTestInfo()
{
EntityName = typeof(LinkedDoc).Name,
EntityCaption = "The linked doc."
};
var grid = Env.Navigation.OpenList(linkedDocEntity);
grid.Toolbar.Click(operationCaption);
var docForm = Env.TabPanel.GetForm(linkedDocEntity.EntityName);
docForm.GetField<TextField>(ReflectionHelper.GetMemberInfo<LinkedDoc>(f => f.Caption).Name).SetText("Boo-yaa!");
docForm.Toolbar.Click("Создание", "Завершить операцию {0}".FormatWith(operationCaption));
docForm.Toolbar.Click("Черновик", "AutoGenerated {0}".FormatWith("Создать SampleDoc из текущей операции"));
var sampleDocEntity = new EntityTestInfo()
{
EntityName = typeof(SampleDoc).Name,
EntityCaption = "The sample doc."
};
var newDocForm = Env.TabPanel.GetForm(sampleDocEntity.EntityName);
var caption = newDocForm.GetField<TextField>(ReflectionHelper.GetMemberInfo<SampleDoc>(f => f.Caption).Name).GetValue();
Assert.AreEqual("Boo-yaa!", caption, "Кэпшен созданого документа отличается от ожидаемого");
}
Да, да, Вилен, вот так это делается. Куча тестов, тщательный подбор событий, пробы, ошибки, правки… Годы работы. А не «а не зафигарить ли нам такую фичу!?».
Тут нет никакой сигнатуры параметров. Очевидно что назначение параметра определяет его позиция, а это не очень хорошо, т.е. при изменении сигнатуры могут быть большие проблемы с отладкой и совместимостью. Да и запрос не самодокументируемый вышел.
При этом ответ с данными — одномерный массив. Насколько я понял все передается одним махом, т.е. пэйджинг клиентский.
В общем на вкус и цвет. Просто отметил техническую часть.
Симпотично у вас, а главное достаточно шустрый DOM, который можно навернуть до нужной красоты.
А вот транспорт не особо приятный, все же пулять весь набор одномерным массивом как-то… есть же JSON. И запрос данных тоже, на мой вкус, слишком миниатюрен. Может просто я против гиперминимизации данных… Но чую огребетесь вы на этом. Экономия на битах до добра не доводит.
Или открыть ателье по изготовлению автодомов. Ей богу, там начинка тыщ на 200-300, а база — обычный автомобиль/джип/автобус. Берем ПАЗ-ик, и ПАЗ-ик превращается, превращается…
Да вы, батенька, тролль. Я уж было хотел ответить, но понял что ответ вас не интересует. Кратко — 1С крутые ребята, проблемы описаны в комментах выше. В этой ветке больше не отвечу.
Вот самое интересное — это «А от редактирования собственно объектов в табличном виде в управляемом приложении ушли сознательно: объекты редактируются только в формах.». Остальное я и назвал — «ограничения». Слишком много терминологии в обсуждении таких вопросов возникает. За ней теряется логика :\
У нас есть такая фича, как закрепляемые колонки. Если в списке 50 колонок (и аналитикам никто руки не оторвал), то юзеру сложно ориентировать при горизонтальной прокрутке. Можно закрепить колонки, тогда они не будут прокручиваться, останутся на месте, а прокручиваться будут незакрепленные. В общем-то можно было бы попробовать вашу идею (надеюсь вы её ещё не запатентовали?) :) Во всяком случае я опустил руки перед этой задачей… Хотя может и сработает %)
Сложно тут сказать что-то совсем конкретное. В целом есть два этапа ввода редактируемого грида (как по мне):
1) Отделение данных от представления. На клиент приходят сырые данные и на клиенте они уже красиво показываются. Это можно увидеть в HTTP запросах от грида. Теперь можно использовать поля редактирования, слегка адаптированные, но в целом как на форме.
2) Интеграция событий полей и всего с ней связанного в поля редактирования на гриде. Для этого нужно как-то использовать богатые механизмы формы, на которых реализованы события поле, ПУЗ-ы, изменения данных с сервера в ответ на изменение состояния записи.
И тут возникает куча нюансов, типа динамическое изменение доступности, видимости редактируемого поля.
Есть ещё вариант всё брать с сервера, т.е. грид фактически не редактируемый. Из него вызывается событие редактирования, с сервера приходит значение редактируемой ячейки, и все управляется на сервере. Тут будет много проблем далее по пути. Как хранить изменяемую запись на сервере в промежутках между изменениями, если никак, то что делать с неатомарными изменениями.
Вот ориентируясь на такие моменты можно понять насколько полная реализация в той, или иной системе. Боюсь отвечать совсем конкретно, т.к. я могу что-то упустить и принизить достоинства других систем. Хотя все они очень крутые и хорошо делают свое дело (плохие я в обзор не включал).
Спасибо! Сейчас много систем метит в облака, мы (я один из ведущих разработчиков Oreodor, делаю View) в этом направлении года 3-4 работаем. Текущая итерация (3-я версия платформы) почти два делается. Не знаю точно сколько 1С свой веб клиент разрабатывают, но у них, судя по моему анализу, есть некоторые сложности с преемственностью предыдущих версий, в том числе и настольных.
В общем на этом направлении много чего интересного происходит, война за рыкон только начинается.
Редактируемость гридов вообще штука сложная. Там нет ПУЗ-ов, ограничения на DataBinding-и, на неатомарные операции, не все типы данных можно редактировать. Редактируемая сущность должна быть простой. Вообще куча ограничений на это везде. Я не хочу сказать что 1С плохой, а FinoBox хороший, вовсе нет. Просто обозначил сложный момент. Ни одна система, из тех что я видел, не реализовала полноценный редактируемый грид, везде есть мирриады ограничений навроде тех, что я перечислил.
Хехе, чистый HTML + JS! Я бы даже сказал отборный. Потыкайтесь, там интересно организованы окна в отдельном браузере. У них это уже года 2-3 как работает, в этой самой демке. Ребята молодцы, у них много интересных решений.
Хорошее решение. Нужно ещё добавить снятие всех сортировок, и как-то показывать пользователю что хоть одна сортировка установлена (как кнопка фильтры). Тогда даже если колонка прокручена горизонтальным скролом, видно что где-то что-то отсортировано.
Но при множественной сортировке важнее порядок, в котором были установлены сортировки. Вот это показать, сложнее (чтоб выглядело просто). А самое сложное — управлять порядком, ведь все сводится к Order by «Field1» then by «Field2» then by «Field3»… типа того.
И вот тут затык получается, и, в конечном итоге, выносят это все в отдельное окно настройки :\ Я пробовал много вариантов, интуитивно и легко для пользователя не вышло.
А как вы параллелите тесты Selenium? Я в эту сторону особо не копал, у нас они выполняются в пределах 30-40 минут, ввиду их немногочисленности. Есть мысли покопать в сторону Selenium Grid.
В целом у нас считается что тесты через UI имеют наименьшую ценность. Все покрывается Unit тестами, в том числе и бизнес логика. Хотя есть целое API для быстрого написания устойчивых тестов Selenium, но менеджмент не считает это возможностью как-то упростить жизнь ручным тестеровщикам (к слову редко кто воспринимает тесты через UI всерьез, по моим наблюдениям). Может у вас есть весомый комментарий к этому, как повлиять на такое мировоззрение менеджмента?
Тестируем мы вот это (например): Пример решения на платформе
А тесты выглядят так (мы завязываемся на серверную реализацию, и управляем UI с точки зрения более высокоуровневых объектов, таких как форма, кнопка, поле ввода, список, вкладка, окно, а не HTML элементов):
в Post видно:
7|0|7|http://finbudgetgrid.appspot.com/finbudgetgriddemo/|4BE165E7793F80BC7F914760A3BBE44A|com.gwtplatform.dispatch.shared.DispatchService|execute|java.lang.String/2004016611|com.gwtplatform.dispatch.shared.Action|finbudgetgriddemo.client.grid.GetDataAction/1094887940|1|2|3|4|2|5|6|0|7|50|
Тут нет никакой сигнатуры параметров. Очевидно что назначение параметра определяет его позиция, а это не очень хорошо, т.е. при изменении сигнатуры могут быть большие проблемы с отладкой и совместимостью. Да и запрос не самодокументируемый вышел.
При этом ответ с данными — одномерный массив. Насколько я понял все передается одним махом, т.е. пэйджинг клиентский.
В общем на вкус и цвет. Просто отметил техническую часть.
А вот транспорт не особо приятный, все же пулять весь набор одномерным массивом как-то… есть же JSON. И запрос данных тоже, на мой вкус, слишком миниатюрен. Может просто я против гиперминимизации данных… Но чую огребетесь вы на этом. Экономия на битах до добра не доводит.
Коммьюнити лицензия бесплатная, вроде бы на основе GNU AGPLv3.
Карта выбора их лицензии (есть по ссылке):
Самая дешевая лицензия на одного разработчика стоит $329. Прайсы тут.
1) Отделение данных от представления. На клиент приходят сырые данные и на клиенте они уже красиво показываются. Это можно увидеть в HTTP запросах от грида. Теперь можно использовать поля редактирования, слегка адаптированные, но в целом как на форме.
2) Интеграция событий полей и всего с ней связанного в поля редактирования на гриде. Для этого нужно как-то использовать богатые механизмы формы, на которых реализованы события поле, ПУЗ-ы, изменения данных с сервера в ответ на изменение состояния записи.
И тут возникает куча нюансов, типа динамическое изменение доступности, видимости редактируемого поля.
Есть ещё вариант всё брать с сервера, т.е. грид фактически не редактируемый. Из него вызывается событие редактирования, с сервера приходит значение редактируемой ячейки, и все управляется на сервере. Тут будет много проблем далее по пути. Как хранить изменяемую запись на сервере в промежутках между изменениями, если никак, то что делать с неатомарными изменениями.
Вот ориентируясь на такие моменты можно понять насколько полная реализация в той, или иной системе. Боюсь отвечать совсем конкретно, т.к. я могу что-то упустить и принизить достоинства других систем. Хотя все они очень крутые и хорошо делают свое дело (плохие я в обзор не включал).
В общем на этом направлении много чего интересного происходит, война за рыкон только начинается.
Но при множественной сортировке важнее порядок, в котором были установлены сортировки. Вот это показать, сложнее (чтоб выглядело просто). А самое сложное — управлять порядком, ведь все сводится к Order by «Field1» then by «Field2» then by «Field3»… типа того.
И вот тут затык получается, и, в конечном итоге, выносят это все в отдельное окно настройки :\ Я пробовал много вариантов, интуитивно и легко для пользователя не вышло.