>
> Правильно, и я эти довольно веские причины уже описывал
> выше:
> 1) Заказчик это хочет
> 2) Это технически возможно.


И тебе уже неоднократно отвечали, как и с редактированием в гриде:
1) Заказчик готов это оплатить
2) Заказчик готов оплатить потом переделку этого "взад", если он осознает, что хотел "странного".
При выполнении этих пунктов - пуркуа бы и не па?
"Желание клиента - закон" выполняется только в одном случае: это действительно клиент, а не "потенциальный клиент".

Ega23 ©   (10.01.12 13:35) [140]

Естественно. Тогда об чем спор вообще? :)

> Естественно. Тогда об чем спор вообще? :)


Да нету никакого спора.
Но, согласись, в случае [0] с вероятностью 99% - это тупо незнание технологий, архитектур и вообще дилетантство.

> Но, согласись, в случае [0] с вероятностью 99% - это тупо
> незнание технологий, архитектур и вообще дилетантство.


Не соглашусь. С вероятностью 1%. Наверное, об этом и спор :) У разных людей разный опыт. Если на экране есть кнопка "Refresh", то должен быть и checkbox "AutoRefresh"

+ еще комбобокс "Каждые N секунд"

> Ega23 ©   (10.01.12 13:40) [142]

> Да нету никакого спора.

Спор есть, т.к. некоторые товарищи сразу отнесли саму возможность автообновления в разряд фантастики.

to Компромисс ©   (10.01.12 13:12) [128]:

> Они один раз загружают все данные (минута-две), пока чай
> пьют, потом уже только работают и не хотят времени терять.
>

Конечно, если обновление выборки занимает столько, что можно сходить чаю попить, то вопросов нет, надо что-то придумывать. Мы придумали - у нас в типичной ситуации на рабочем месте отображается несколько десятков записей и время обновления выборки мало отличается от времени нажатия на кнопку. 400 тыс записей не вываливаются из реальных выборок нигде. Они не нужны.


> Фильтрация на клиенте очень быстрая, даже быстрее, чем на
> сервере,  

Что-то слабо себе представляю ситуацию, в которой система фильтрации на клиенте будет работать быстрее, чем на сервере. Особенно, если критерий подразумевает некие вычисления по связанным данным.


> учитывая, что есть сложная система контроля доступа и пользователь
> не всё должен видеть (мягко говоря).

У нас тоже. Но работает это все, сюрпрайз, на уровне сервера. А клиентский код о системе контроля доступа к данным, как правило, вообще не догадывается. Правда, каким боком эт к автообновлениям - мне вообще не понятно. :)

>  то должен быть и checkbox "AutoRefresh"
> + еще комбобокс "Каждые N секунд"


Это цепляется за 2 секунды. Речь не об авторефреше, а о событийной модели. а это уже не так просто и однозначно.

to знайка   (10.01.12 13:28) [134]:


> Так вы сами про ридонли
> ситуацию привели.

Я привел ситуацию не столько ридонли, сколько такую, когда (на мой взгляд) от автообновления имеем один только вред.

to Компромисс ©   (10.01.12 13:46) [143]

> Если на экране есть кнопка
> "Refresh", то должен быть и checkbox "AutoRefresh"

И зачем дергать данные, которые понадобятся с вероятностью, близкой к нулю?

> asail ©   (10.01.12 13:29) [136]
>
> > Павел Калугин ©   (10.01.12 10:27) [95]
>
> > > Разницу между клиентом и пользователем осознаем?
> >
> > И в чем разница? Данные у пользователя обновляются не
> по
> > инициативе сервера. Как это реализовано - он сам капу
> давит
> > или таймер шуршит дело десятое.
>
> Вот это ты пользователю объясни... Еще раз, пользователю
> по-барабану, сервер ли рассылает сообщения об изменениях
> или клиент стучится до сервера по таймеру. Да хоть, сисадмин
> будет каждые две минуты с флешкой прибегать и обновлять
> данные... Все это - различные способы технической реализации
> одной и той же функциональности, и с точки зрения пользователя,
>  значения не имеют.

Сээр, ну вы просто пользователь? Ну тогда Вам все равно. Иначе сами должны понимать разницу между

> если пользователь 1 изменил какую-то информацию, у других
> пользователей эти изменения отобразились автоматом

и когда клиентское приложение отправляет запрос на получение обновленных данных (по капе или как это абсолютно все равно)

> 400 тыс записей не вываливаются из реальных выборок нигде.
>  Они не нужны.


Мне тоже. Клиент хочет :)


> Что-то слабо себе представляю ситуацию, в которой система
> фильтрации на клиенте будет работать быстрее, чем на сервере.
>  Особенно, если критерий подразумевает некие вычисления
> по связанным данным.


Вот именно. На сервере происходит поиск во многих таблицах, проверка прав, вычисления, в итоге хранимая процедура выполняется порядка 30 секунд. На клиенте фильтрация занимает до 2 секунд, потому что все данные уже есть и выполняются только проверки на соответствие фильтру, причем как бы по одной таблице (в массиве).


> Но работает это все, сюрпрайз, на уровне сервера.


Обижаешь :) У нас всё тоже очень серьезно в плане безопасности. Детали не скажу, конечно :)

Во раздули-то..
Кстати, основная фишка аппаратов Блэкберри в том, что там письма приходят мгновенно, а не пока аппарат проверит почту по таймеру. Двусторонняя связь - удобная штука.

> asail ©   (10.01.12 13:54) [145]
>
> > Ega23 ©   (10.01.12 13:40) [142]
>
> > Да нету никакого спора.
>
> Спор есть, т.к. некоторые товарищи сразу отнесли саму возможность
> автообновления в разряд фантастики.

Не совсем. Дословно - неоправданные требования автообновления отнесены в область бреда заказчика. Со всеми вытекающими. Как выше Олег писал, если заказчик регулярно оплачивает реализацию своего очередного бреда и адекватно переносит сроки сдачи - почему бы и нет. Но итоговым счетом и сроками заказчик все равно будет не доволен

> Это цепляется за 2 секунды. Речь не об авторефреше, а о событийной модели. а это уже не так просто и однозначно.
+1
приводил уже пример/вопрос, что делать, при редактирование чего то  (документа например) по связанному списку, и вдруг внешним редактированием удаляется связь.
если блокировать на время... то нафиг оно вообще нужно, тому кто работает, он же всегда что-то делает, и это блокирует авто обновления...
а закончив он получает обновленный список по событию завершения (получить результат своих же действий, заодно и всех остальных).

вот и выходит единственное кому это нужно (в этом варианте) это бездельничающему начальнику.

> основная фишка аппаратов Блэкберри в том, что там письма приходят мгновенно
всем, или все-таки адресно?

sniknik ©   (10.01.12 14:17) [154]

Этот пример можно и в другую сторону использовать. Зачем читать документ, который уже был удален???

> вот и выходит единственное кому это нужно (в этом варианте)
> это бездельничающему начальнику.


Ну не только. В моём очень конкретном случае - дежурному прапорщику на пульте контроля. Всякие сообщения от датчиков смотреть. Где-то тревога (по различным причинам), где-то warning, мол, в самотестирование ушло, где-то просто информационные сообщения.
Но, опять же, это исключительно read-only режим. И не более N записей на оперативном экране. Надо больше - будьте любезны в архив, с фильтрами, условиями выборки и т.п.

И, опять же, это очень-очень частный случай. В параллельном модуле "Бюро Пропусков" никакого автообновления не было, хотя и записей было нормально, и работало пару десятков человек одновременно. И никаких жалоб или "сделайте вот так" не было.

> Зачем читать документ, который уже был удален???
почему удален? ссылка изменена, а новая в выбранный фильтр не попадает. да и вообще это может быть временное изменение.

> Этот пример можно и в другую сторону использовать. Зачем
> читать документ, который уже был удален???


почему бы и нет? Вот у меня в notepad++ был открыт некий файл. Который я потом взял и удалил с диска. Почему он должен у меня закрыться в notepad?

> Всякие сообщения от датчиков смотреть.
о блин, а у нас тоже есть подобное, система ошибок для дежурного администратора... но вот как то я ее не воспринимаю как программу по работе с субд... единственное чтение, и показ больше ничего не делает.
да еще с автообновлением, это единственное что она делает, т.е. не авто, но просто процесс.