Здравствуйте, Sinclair, Вы писали:
L>>А можно подробнее, как у CustomerViewModel будет выглядет свойство Locations? Уж не List<Dictionary<string, object>> ли? S>Скорее всего — Dictionary<Guid, string>. Потому что очень вряд ли на одной странице нужны ОО-детали от Location.
Мне сложно принять такое на веру. Это какой-то super-busy UI получается. Вон, ты даже скриншот его не можешь прислать. S>>Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo. L>Куда "туда"?
Туда — это в тот UI, в котором они потребовались.
Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI. Тем не менее, он почти весь построен на списках строк с идентификаторами. Всё остальное отображается в отдельных View, которые отдельно проектируются. Тут как-бы довольно странно жаловаться на то, что тебе в одном месте нужно описать, какие именно компоненты Location тебе нужны в LocationHintInfo.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Мне сложно принять такое на веру. Это какой-то super-busy UI получается.
Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.
S>Вон, ты даже скриншот его не можешь прислать.
Открой какой-нить 1С, да посмотри. Куда поще-то?
S>>>Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo. L>>Куда "туда"? S>Туда — это в тот UI, в котором они потребовались.
Что значит "затащить LocationInfo в UI"?
S>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI.
В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.
S>Тем не менее, он почти весь построен на списках строк с идентификаторами. Всё остальное отображается в отдельных View, которые отдельно проектируются. Тут как-бы довольно странно жаловаться на то, что тебе в одном месте нужно описать, какие именно компоненты Location тебе нужны в LocationHintInfo.
А последнее предложение я вообще не понял. Откуда взялся LocationHintInfo?
S>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается. L>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.
"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
S>>Вон, ты даже скриншот его не можешь прислать. L>Открой какой-нить 1С, да посмотри. Куда поще-то?
1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс.
И надо прилагать усислия чтобы его упростить.
S>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI. L>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.
Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.
Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться.
Кстати поэтому навигация на постбеках — зло.
Здравствуйте, gandjustas, Вы писали:
G>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
Здравствуйте, EvilChild, Вы писали:
EC>Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?
А вопрос-то не так прост. Всегда, когда мы делаем динамическое приведение типа, мы имеем диспетчеризацию как минимум на 2 ветки — успешную и неуспешную. А если еще поднятся на шаг выше, то динамическое приведение обычно и используется там, где предполагается некая _группа_ типов, иначе можно обойтись статической типизацией.
---------
Согласен, что матчинг помимо подобного динамического определения типа еще умеет и значения матчить. Так же напомню, что шли обсуждения конструкций для C# типа этой:
switch(obj.GetType()) {
case typeof(A): ...
case typeof(B): ...
}
Но, думается, вместо подобной билеберды введут все-таки матчинг, ибо он более удобен в этих самых задачах, для которых сегодня используется динамическая типизация.
Здравствуйте, gandjustas, Вы писали:
A>>Исходный посыл был, что кеш не являющийся локальной репликой во многих случаях просто бесполезен. G>Интересно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать.
Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
G>>>Бред, в "большом бизнесе" интернет есть в кажом офисе. A>>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два. G>А где же еще делается "большой бизнес"?
Вне офиса
G>И почему не может полагаться на работоспособность инета?
А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.
G>Интернет — самая надежная сеть на сегодняшний момент.
Из общедоступных, как минимум GSM сети надёжнее интернета.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Исходный посыл был, что кеш не являющийся локальной репликой во многих случаях просто бесполезен. G>>Интересно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать. A>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
И каким образом должно учитываться содержание?
G>>>>Бред, в "большом бизнесе" интернет есть в кажом офисе. A>>>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два. G>>А где же еще делается "большой бизнес"? A>Вне офиса
Ну где? Конкретнее.
G>>И почему не может полагаться на работоспособность инета? A>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.
Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают.
Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть.
Если нужно взаимодействие между несколькими крупными офисами, то интранет решения в каждом из них могут обмениваться информацией через веб-сервисы и репликацию БД.
G>>Интернет — самая надежная сеть на сегодняшний момент. A>Из общедоступных, как минимум GSM сети надёжнее интернета.
Мда.. сравнивать средства канального уровня и сетевого конечно круто.
Здравствуйте, vdimas, Вы писали:
EC>>Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?
V>А вопрос-то не так прост. Всегда, когда мы делаем динамическое приведение типа, мы имеем диспетчеризацию как минимум на 2 ветки — успешную и неуспешную. А если еще поднятся на шаг выше, то динамическое приведение обычно и используется там, где предполагается некая _группа_ типов, иначе можно обойтись статической типизацией.
Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?
V>--------- V>Согласен, что матчинг помимо подобного динамического определения типа еще умеет и значения матчить.
Да нет там динамического определения типа. Мы матчимся по значениям одного типа.
Это тупо свитч на стероидах. V>Так же напомню, что шли обсуждения конструкций для C# типа этой: V>
V>switch(obj.GetType()) {
V> case typeof(A): ...
V> case typeof(B): ...
V>}
V>
V>Но, думается, вместо подобной билеберды введут все-таки матчинг, ибо он более удобен в этих самых задачах, для которых сегодня используется динамическая типизация.
Я здесь исключительно про ПМ в хаскеле.
now playing: Alex Under — Las Bicicletas Son Para El Verano (Alex Smoke's Rusty Bike Mix)
S>>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается. L>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо. G>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.
S>>>Вон, ты даже скриншот его не можешь прислать. L>>Открой какой-нить 1С, да посмотри. Куда поще-то? G>1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс. G>И надо прилагать усислия чтобы его упростить.
PE-то будет?
S>>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI. L>>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно. G>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.
В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.
G>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться. G>Кстати поэтому навигация на постбеках — зло.
Здравствуйте, adontz, Вы писали: A>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
Что, серъезно? В каком смысле "не учитывает содержание"? В каком смысле "учитывается тип"?
Кому-то из нас нужно перечитать RFC.
A>Вне офиса
Прикольно. Посмотреть бы еще на этот большой бизнес.
Вот у нас, к примеру, маленький. Вот неполный список офисов: http://www.parallels.com/contact/. Пока что все работает по интернету. Даже телефонов у нас обычных не выдают, стоят IP-Phones. А тем, кто часто бывает вне офиса, рекомендуют использовать скайп.
A>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.
A>Из общедоступных, как минимум GSM сети надёжнее интернета.
То есть интернет по GPRS надежнее интернета. Прикольно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается. L>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо. G>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
L>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.
Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.
S>>>>Вон, ты даже скриншот его не можешь прислать. L>>>Открой какой-нить 1С, да посмотри. Куда поще-то? G>>1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс. G>>И надо прилагать усислия чтобы его упростить. L>PE-то будет?
В 1с ?
S>>>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI. L>>>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно. G>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками. L>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.
Это уже отмазка.
Без компьютеров люди могут управляться с весьма малым количеством сущностей и их атрибутов.
В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей.
При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим.
G>>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться. G>>Кстати поэтому навигация на постбеках — зло. L>Не уходи от темы. Я все еще жду правильных PE.
См выше.
Вообще говоря без кода я вряд ли смогу что-нить адекватое предложить.
Здравствуйте, Sinclair, Вы писали:
A>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер. S>Что, серъезно? В каком смысле "не учитывает содержание"? В каком смысле "учитывается тип"? S>Кому-то из нас нужно перечитать RFC.
RFC тут не при чём. Есть сайт, у его HTMLок (ну или генерируемого активными страницами HTML кода) стандартные заголовок и окончание. Отдельно их кешировать нельзя.
A>>Вне офиса S>Прикольно. Посмотреть бы еще на этот большой бизнес.
Антон, приводить IT компанию как пример довольно нелепо.
A>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня. A>>Из общедоступных, как минимум GSM сети надёжнее интернета. S>То есть интернет по GPRS надежнее интернета. Прикольно.
Нет. Именно GSM надёжнее.
Здравствуйте, gandjustas, Вы писали:
G>>>Интересно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать. A>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер. G>И каким образом должно учитываться содержание?
Например, могли бы кешироваться одинаковые фрагменты страниц, картинок.
A>>Вне офиса G>Ну где? Конкретнее.
А что тут не конкретного?
A>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня. G>Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают.
Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.
G>Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть. G>Если нужно взаимодействие между несколькими крупными офисами, то интранет решения в каждом из них могут обмениваться информацией через веб-сервисы и репликацию БД.
Для которых нужен интернет или личная оптика.
A>>Из общедоступных, как минимум GSM сети надёжнее интернета. G>Мда.. сравнивать средства канального уровня и сетевого конечно круто.
Здравствуйте, adontz, Вы писали:
A>RFC тут не при чём. Есть сайт, у его HTMLок (ну или генерируемого активными страницами HTML кода) стандартные заголовок и окончание. Отдельно их кешировать нельзя.
И не нужно. Потому, что в общем случае для HTML эта проблема неразрешима — нет средств выражения "общих частей".
Зато в частных случаях эта проблема разрешима — достаточно порезать документ на фрагменты, которые можно кэшировать независимо. Эту технику с успехом демонстрируют современные сайты типа pageflakes. Для типичных в приложениях "документов-списков" есть стандартное решение для delta encoding, которое позволяет выполнять частичное обновление с гранулярностью меньше документа.
Для всех остальных случаев, когда HTTP используется не стандартным браузером, есть стандартизованные способы расширения протокола, которые позволяют всё то, чего ты хочешь. A>Антон, приводить IT компанию как пример довольно нелепо.
А кого надо приводить? Вот есть katren.ru. У них филиальная сеть поширше, чем у нас. Не поверишь — тоже интернет пользуют A>Нет. Именно GSM надёжнее.
Что ты имеешь в виду? Голос по GSM? Рома, это даже не смешно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>>>Интересно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать. A>>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер. G>>И каким образом должно учитываться содержание?
A>Например, могли бы кешироваться одинаковые фрагменты страниц, картинок.
Имхо затраты на обощенную схему "фрагментизации" докуметов и кеширование фрагметнами могут оказаться больше, чем передавать фрагмент еще раз.
При желании сам разработчик может разбит документ на несколько.
A>>>Вне офиса G>>Ну где? Конкретнее. A>А что тут не конкретного?
Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире.
Так что давай конкретнее.
A>>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня. G>>Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают. A>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.
Так они банально платят деньги чтобы получить 99,999% работосособности.
G>>Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть. G>>Если нужно взаимодействие между несколькими крупными офисами, то интранет решения в каждом из них могут обмениваться информацией через веб-сервисы и репликацию БД. A>Для которых нужен интернет или личная оптика.
Нужен, только не постоянно.
Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.
A>>>Из общедоступных, как минимум GSM сети надёжнее интернета. G>>Мда.. сравнивать средства канального уровня и сетевого конечно круто. A>Уверен, что GSM сеть это канальный уровень?
Да
Здравствуйте, gandjustas, Вы писали:
L>>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо. G>>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
L>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать. G>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.
Ну так приведи ее? Или это настолько редкая задача? G>>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками. L>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только. G>Это уже отмазка.
Какая еще отмазка? Это совершенно разные классы приложений.
G>Без компьютеров люди могут управляться с весьма малым количеством сущностей и их атрибутов. G>В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей. G>При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим.
Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность.
Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности.
G>>>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться. G>>>Кстати поэтому навигация на постбеках — зло. L>>Не уходи от темы. Я все еще жду правильных PE. G>См выше. G>Вообще говоря без кода я вряд ли смогу что-нить адекватое предложить.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо. G>>>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.
L>>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать. G>>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы. L>Ну так приведи ее? Или это настолько редкая задача?
Покажи код. Умением "лечит геморрой по фотографии" не обладаю.
G>>>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками. L>>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только. G>>Это уже отмазка. L>Какая еще отмазка? Это совершенно разные классы приложений.
Принципы хорошего UI не зависит от класса приложений.
G>>Без компьютеров люди могут управляться с весьма малым количеством сущностей и их атрибутов. G>>В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей. G>>При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим. L>Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность. L>Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности.
Это были общие размышения.
Конкретно по твоему случаю без кода сказать ничего не могу.
Здравствуйте, gandjustas, Вы писали:
L>>>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать. G>>>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы. L>>Ну так приведи ее? Или это настолько редкая задача? G>Покажи код. Умением "лечит геморрой по фотографии" не обладаю.
Код чего?
L>>>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только. G>>>Это уже отмазка. L>>Какая еще отмазка? Это совершенно разные классы приложений. G>Принципы хорошего UI не зависит от класса приложений.
Ладно, проехали. Пусть будет так.
PE-то будут?
L>>Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность. L>>Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности. G>Это были общие размышения.
Не надо общих размышлений по вполне конкретному вопросу.
G>Конкретно по твоему случаю без кода сказать ничего не могу.
