Гм, да, действительно, один из пяти раз съежжает. Походу картинка подгружается раньше чем заголовок отрисовывается — из за этого и проблема.
PS только хотел написать bugreport — перестало повторяться. Пичаль. :(
Об этом было сказано еще три месяца назад. В WinXP нету DirectX10 а следовательно Direct2D. В том числе поэтому IE9 там не будет. Ну и XP уже кагбе отжила свое, ничего кроме WinXP SP3 уже не поддерживается, а SP3 тоже медленно но верно изживается. 10 лет операционке как-никак.
Кстати, конкатенация строк плюсом в цикле — дурной тон, у нас например за это п*здят ногами и лишают премии.
BTW, при конкатенации строк происходит создание объекта StringBuilder, выполнение append-ов всех строк и потом вызов .toString().
ну заведите %user%\Application Data\app\profile1, %user%\Application Data\app\profile2
и сделайте два ярлыка. в одном c:\program files\app\app.exe -p profile1, в другом — c:\program files\app\app.exe -p profile2
Стоп, непонял. А что, для контролов данные не нужно подготавливать?
Пример: есть контрол, отображающий данные в таблице. На входе у контрола — коллекция каких-либо Item-ов. Контрол умеет отобразить эту коллекцию.
Т.е. задача вьюхи — связать контрол с коллекцией
Теперь представим себе такую ситуацию: нужно отобразить только те Item-ы для которых Criteria(Item) == true.
В случае MVC — получаем все items из модели, проверяем и берем только те которые соответствуют критерию.
В случае MVVM — ViewModel отвечает за подготовку данных, в том числе и фильтрацию. Т.е. View тупо, без какой либо логики берет коллекцию из ViewModel и отдает контролу. Логика проверки Item-ов на соответствие критерию — во ViewModel.
>А если не пользователю (а в дизайне жестко прошито)?
ну тогда либо культуру жестко во ViewModel зашить, либо форматировать во вьюхе, я вам об этом уже написал.
>Зато не имеем проблем с тем, где что определяется и меняется.
В случае MVVM тоже — все данные для представления подготавливаются во ViewModel, это его ответственность. Ответсвенность вьюхи — взять данные и пульнуть на страницу _без какой-либо обработки_.
>Особенно это место становится смешным, когда выясняется, что за отображение даты начинает отвечать control на стороне view, и ему надо передавать datetime объектом.
Я не пытаюсь вам продать MVVM (паттерны всякие нужны, паттерны всякие важны), я пытаюсь показать вам, в каких случаях ваше изначальное замечание «А вот это, очевидно, глупость.» неверно.
«Это означает, что стоит нам захотеть поменять формат вывода (длинная дата — короткая) нам придется править код где-то в маппере model-viewmodel. В то время как это отчетливая функция презентационного слоя. „
А как вам такой пример использования: пользователю дается выбор текущей культуры и формата. Такие настройки явно будут храниться в модели. И тут либо мы имеем логику по формированию строки во ViewModel (не забываем, что этот уровень отвечает за подготовку данных для View) либо логику во View.
Причем если логику работы ViewModel в данном случае мы можем проверить тестами, то логику работы View — тока визуально оценив как оно отформатировалось в HTML.
Summary: в случае использования паттерна Model-View-Controller — ваш подход оправдан, но имеем проблемы с тестированием View.
В случае использования паттерна Model-View-ViewModel подготовка данных для отображения должна быть максимально сконцентрирована во ViewModel, при этом View должна быть тупой с минимумом логики. В этом случае можно будет на ViewModel написать тесты на проверку форматирования/подготовки данных, реакции на команды, etc. А т.к. задача View только отобразить уже готовые данные — скорее всего все сразу и заработает.
Я думаю тут имелось в виду вот что: в модели хранится дата в виде DateTime или как его там. Плюс хранится поле Timezone и Culture. При подготовке данных для представления (т.е. во ViewModel) дата пересчитывается на основе Timezone, форматируется в зависимости от текущей Culture и отдается в виде строки.
За образец берется здравый смысл и стандартные (либо привычные) расположения кнопок, а про то, кто и что у кого передирает мы беседовали разве что в школе. Может имеет смысл повзрослеть немного?
Эге как вас задело-то :) Я думаю МС не в обиде на KDE за копирование хороших идей/реализаций. Как собсно и наоборот.
И давно это в тандерберде можно в два клика и без плагинов сделать «напомнить про письмо через два дня»? Ну и календаря в ТБ тож как-то не наблюдается. Почтовый клиент — ага. Но не полнофункциональный :)
Знаете, я оутлук тоже долго не мог оценить. Пока не пришлось вплонтую заниматься теми вещами для которых он предназначен. :)
Решает — возможно. Насчет успешно: а вы сами-то работали со всем этим делом?
Для home почты мне например gmail хватает. Рабочие дела без outlook — никак.
ЗЫ посмотрел скриншоты/фичи KOrganizer. Ну как вам сказать… Вы догадываетесь какое приложение создатели korganizer берут за образец? ;)
ЗЫ английский бинг для запроса «klite mega» так же как и гугл работает.
PS только хотел написать bugreport — перестало повторяться. Пичаль. :(
Exactly! :)
BTW, при конкатенации строк происходит создание объекта StringBuilder, выполнение append-ов всех строк и потом вызов .toString().
и сделайте два ярлыка. в одном c:\program files\app\app.exe -p profile1, в другом — c:\program files\app\app.exe -p profile2
>теперь отвечает контрол, который часть view
А для контрола — свой ViewModel :)
>Контроллер формирует модель, содержащую только нужные данные, а view их
>отображает все целиком.
… ну или так :)
Пример: есть контрол, отображающий данные в таблице. На входе у контрола — коллекция каких-либо Item-ов. Контрол умеет отобразить эту коллекцию.
Т.е. задача вьюхи — связать контрол с коллекцией
Теперь представим себе такую ситуацию: нужно отобразить только те Item-ы для которых Criteria(Item) == true.
В случае MVC — получаем все items из модели, проверяем и берем только те которые соответствуют критерию.
В случае MVVM — ViewModel отвечает за подготовку данных, в том числе и фильтрацию. Т.е. View тупо, без какой либо логики берет коллекцию из ViewModel и отдает контролу. Логика проверки Item-ов на соответствие критерию — во ViewModel.
ну тогда либо культуру жестко во ViewModel зашить, либо форматировать во вьюхе, я вам об этом уже написал.
>Зато не имеем проблем с тем, где что определяется и меняется.
В случае MVVM тоже — все данные для представления подготавливаются во ViewModel, это его ответственность. Ответсвенность вьюхи — взять данные и пульнуть на страницу _без какой-либо обработки_.
>Особенно это место становится смешным, когда выясняется, что за отображение даты начинает отвечать control на стороне view, и ему надо передавать datetime объектом.
Я не пытаюсь вам продать MVVM (паттерны всякие нужны, паттерны всякие важны), я пытаюсь показать вам, в каких случаях ваше изначальное замечание «А вот это, очевидно, глупость.» неверно.
А как вам такой пример использования: пользователю дается выбор текущей культуры и формата. Такие настройки явно будут храниться в модели. И тут либо мы имеем логику по формированию строки во ViewModel (не забываем, что этот уровень отвечает за подготовку данных для View) либо логику во View.
Причем если логику работы ViewModel в данном случае мы можем проверить тестами, то логику работы View — тока визуально оценив как оно отформатировалось в HTML.
Summary: в случае использования паттерна Model-View-Controller — ваш подход оправдан, но имеем проблемы с тестированием View.
В случае использования паттерна Model-View-ViewModel подготовка данных для отображения должна быть максимально сконцентрирована во ViewModel, при этом View должна быть тупой с минимумом логики. В этом случае можно будет на ViewModel написать тесты на проверку форматирования/подготовки данных, реакции на команды, etc. А т.к. задача View только отобразить уже готовые данные — скорее всего все сразу и заработает.
ЗЫ факапы бывают, фигли.
За образец берется здравый смысл и стандартные (либо привычные) расположения кнопок, а про то, кто и что у кого передирает мы беседовали разве что в школе. Может имеет смысл повзрослеть немного?
Эге как вас задело-то :) Я думаю МС не в обиде на KDE за копирование хороших идей/реализаций. Как собсно и наоборот.
Знаете, я оутлук тоже долго не мог оценить. Пока не пришлось вплонтую заниматься теми вещами для которых он предназначен. :)
Для home почты мне например gmail хватает. Рабочие дела без outlook — никак.
ЗЫ посмотрел скриншоты/фичи KOrganizer. Ну как вам сказать… Вы догадываетесь какое приложение создатели korganizer берут за образец? ;)