crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Очень интересная проблема проектирования
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
PAFOS Дата 5.8.2011, 13:53
  Для начала я бы сделал одну модель и два представления. Как ни крути делать две модели для одних и тех же данных неправильно.
Модель будет иметь иерархическую структуру

Проект1
Задача 1
Задача 2
Проект2
Задача 3
Без проекта
Задача 4

Реализация такой модели - дело практики.

Идем далее...

struct Task
{
    int TaskID;
    int ProjectID;
    QString Name;
    QString Notes;
    int Importance;
.......
};

struct Project
{
    int ProjectID;
    QString Name;
    QString Notes;
........
};


заменяем на

struct Task
{
    int TaskID;
    int ProjectID;
    QString Name;
    QString Notes;
    int Importance;

    Project *project  // <- имея на руках экземпляр Task, можем получить доступ к проекту вообще без гемора
.......
};

struct Project
{
    int ProjectID;
    QVector<Task> tasks // <- ну это как бы понятно)
    QString Name;
    QString Notes;
........
};


Такая структура существенно сократит реализацию модели
Однако надо быть внимательным с указателями и т.п.

И напоследок:

Если посмотреть внимательно на класс QAbstractItemView, то можно найти классный метод setRootIndex( QModelIndex )
Для древовидного представления setRootIndex() должен быть QModelIndex::invalid() (т.е. корень модели)
А для списка - выделенный в древовидном представлении QModelIndex типа "Проект".
explorer85 Дата 4.8.2011, 12:14
  Спасибо за ответы, но просто для всего что вы описали в mvc qt есть стандартные вещи: dataChanged, Begin..EndInsertRows итд. Просто оно как бы все уже есть но вот правильно ли я этим пользуюсь в своей ситуации я не знаю.
Вообще по жизни стараюсь придерживаться правила не изобретать велосипеды и если есть что то готовое пользоваться этим. Но за соблюдение этого правила, приходиться расплачиваться необходимостью подстраиваться под чужие уже написанные решения.
Алексей1153 Дата 4.8.2011, 11:30
 
Цитата
Хотя интересно как там сделано))

да очень просто всё сделано (кхм, если работу с АПИшными Tree View и List View можно вообще назвать простыми. Это ад! Но ад программистский, а не
логический) - я делал такую вещь для одной из программ (не на Qt). Главное: отделить GUI от логики и от данных. Окно лишь показывает текущее
состояние данных, а также позволяет ввести новые данные (для создания нового элемента либо для замены содержимого существующего). После
изменения данных окно должно перерисоваться, чтобы показать текущее содержимое данных. Под перерисовкой понимается не принудительная
перерисовка всего, а, возможно, перерисовка только необходимой части окна для отображения изменений. Но само окно понятия не имеет, что поменялось!
Даже несмотря на то, что именно окно помогло ввести данные. Хранилищем окно не управляет - оно передало введённую информацию и забыло.
Перерисовалось. Типа - "я сделало всё, что могло, сотрите, что теперь в данных".
Оба окна не зависят друг от друга. Они зависят от данных. А то, как сортировать, это уже просто - выводят содержимое данных в том виде, в каком
пользователь попросил.

Цитата
зачем таймер если есть сигналы и слоты

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

Цитата
какое я щас вижу решение? делать еще одну связку модель + представление + делегат, передавать модели указатель на Storage с данными
.........ну итд. То есть получается некислое дублирование кода, рост сложности кода проекта ну итд со всеми вытекающими.... И

таймер вновь спешит на помощь :) Сменишь счётчик вхолостую и всё готово.
Кстати говоря, таймер то таймером, он обновит раз в секунду, что нормально для обновления вида других окон (не в фокусе), но не очень то для текущего
окна (сказали сортировать - а оно отреагировало через секунду...) . Тут делаем так: то, что вызывается в обработчике таймера для обновления окон, надо
иметь возможность вызвать в любой момент. Увеличили счётчик вхолостую, вызвали процедуру. Дальше всё по накатанной
explorer85 Дата 4.8.2011, 11:23
 
Цитата(Алексей1153 @ 4.8.2011, 11:48) *
по сути у тебя аналог окна виндового Explorer (дерево папок слева, содержимое папки - справа) только не для файловой системы, а для дерева проектов

Да попал в точку. Щас потыркал проводник та же концепция. Ну только разве что эти два вида у меня доступны не одновременно. А так тоже самое слева проекты, справа задачи)) и если обратил внимание то и модель фильтрации и сортировки для каждого вида тоже своя. Ведь в проводнике если справа в списке сортировать элементы то влевом они остаются в том порядке каком и были. ну это так философия. Хотя интересно как там сделано))

Цитата(Алексей1153 @ 4.8.2011, 11:48) *
Ты упоминаешь, что передаёшь указатель на экземпляр своего класса. При изменениях меняется счётчик. Уведомлений, конечно же, никаких не произойдёт, их надо инициировать. Я бы сделал проверку по таймеру (скажем, раз в секунду) счётчика, и при его изменении обновлял бы представление, которое не в фокусе (тут спорный вопрос - наверное, вместе со счётчиком полезно запоминать инициатора изменений, чтобы его не обновлять)

Да тут все проще зачем таймер если есть сигналы и слоты :rolleyes: Просто я говорил проблема с индексами что нельзя корректно уведомить второе представление об изменениях в первом так как модельные индексы у них разные потому что они связаны с двумя моделями..................

И еще один ньюанс... не хотел пугать просто... Допустим мне захотелось сделать группировку списка задач по каким либо признакам... например по важности (в структуре Task есть такое поле importance) от (0 - 5)
какое я щас вижу решение? делать еще одну связку модель + представление + делегат, передавать модели указатель на Storage с данными .........ну итд. То есть получается некислое дублирование кода, рост сложности кода проекта ну итд со всеми вытекающими.... И я так наверное и сделаю если никто ничего не посоветует выдающегося.... Эх где вы победители школьных олимпиад, эйнштейны, знатоки qt :rolleyes:

Извиняюсь за флуд... но мне почему то кажется что если бы эту тему увидел парень из troolteh котроый писал MVC фреймворк он бы сказал "Не парься брат делай void QAbstractItemModel::reset () для второй модели" :rolleyes:
Алексей1153 Дата 4.8.2011, 10:48
  проблема описана очень ясно и крупно:

Цитата
ПРОБЛЕМА!!!
Данные в моделях и представлениях не синхронизируются между собой!!!
<...>
данные добавляются в QVector <Task> tasks;
модель №2 уведомляется о том что данные добавились

а вот модель и представление №1 НИЧЕГО ОБ ЭТОМ НЕ ЗНАЮТ



по сути у тебя аналог окна виндового Explorer (дерево папок слева, содержимое папки - справа) только не для файловой системы, а для дерева проектов

Ты упоминаешь, что передаёшь указатель на экземпляр своего класса. При изменениях меняется счётчик. Уведомлений, конечно же, никаких не произойдёт, их надо инициировать. Я бы сделал проверку по таймеру (скажем, раз в секунду) счётчика, и при его изменении обновлял бы представление, которое не в фокусе (тут спорный вопрос - наверное, вместе со счётчиком полезно запоминать инициатора изменений, чтобы его не обновлять)
explorer85 Дата 4.8.2011, 10:32
  В том то и дело что я не могу врубиться как организовать правильную работу между своим классом и стандартными интерфейсами QAbstract**Model MVC фреймворка Qt!!! Не понимаю правильно я их настроил для работы (создал два подкласса QAbstractItemModel в них передал указатели на свой класс с данными итд, ну начинаю повторяться уже)


Алексей1153 Ну вообще проблема ясно сформулирована? чтобы мне знать а то может быть и другие люди не поймут? :mellow:
Алексей1153 Дата 4.8.2011, 10:27
  explorer85, да, видимо я что-то не понимаю. Послежу :)
explorer85 Дата 4.8.2011, 10:24
 
Цитата(Алексей1153 @ 4.8.2011, 11:06) *
explorer85, мне тут вот что непонятно: массивы инкапсулированы. Если наружу не выдавать на них ссылок или указателей, то менять содержимое смогут только открытые функции CProjectLibrary. А это означает, что любое изменение можно отследить всегда.


Все правильно, любое изменение можно отследить так как данные в массивах изменяются только с помощью открытых функции CProjectLibrary. Но проблема то не в этом!!!
Еще раз повторюсь есть задача отображать эти данные в двух разных видах указанным способом...(в первом посте я все понятно обьяснил? может просто недопонимание какое то есть)
Я нашел решение которое привел во 2 посте. Проблема в том что я не могу понять правильно ли я сделал применительно к философии mvc в qt или нет, и хочу спросить как бы вы решили эту проблему? :rolleyes:

Я ужасно извиняюсь, ну просто мне кажется что для понимания моей проблемы, нужен человек который имеет опыт написания собствеееных моделей производных от QAbstractItemModel и прокси QAbstractProxyModel

Вот я конечно может быть много прошу но мне нужны как бы два ответа 1 теоретический, о правильности выбранной мной концепции 2 практический применительно этой концепции к конкретным классам QAbstract***Model в Qt

Цитата(Алексей1153 @ 4.8.2011, 11:06) *
Если же пресловутая модель (я не сталкивался ещё пока) не позволяет работать с таким классом совместно, то у меня возникают сомнения насчёт нужности этой самой модели в данном случае.

В том то и дело что я не могу врубиться как организовать правильную работу со этим своим классом MVC фреймворка Qt!!!

Алексей1153 Дата 4.8.2011, 10:06
  explorer85, мне тут вот что непонятно: массивы инкапсулированы. Если наружу не выдавать на них ссылок или указателей, то менять содержимое смогут только открытые функции CProjectLibrary. А это означает, что любое изменение можно отследить всегда.

Если же пресловутая модель (я не сталкивался ещё пока) не позволяет работать с таким классом совместно, то у меня возникают сомнения насчёт нужности этой самой модели в данном случае.


PS нэгодующая модэль : http://i9.photobucket.com/albums/a55/peppe...models/l152.jpg
explorer85 Дата 4.8.2011, 9:34
  Алексей1153, спасибо за совет да с мапами пологичней и побыстрей. А насчет счтечика... дело в том что проекты и задачи отображаютя исключительно но через модели на представлениях и я их пробовал уведомлять сигналом , ну по аналогии с вашим счетчиком, но столкнулся с проблемой описанной в конце способа №1.
Эх неужели никто всерьез не работал с моделями??? перечитал эту ветку за год похожие проблемы вроде встречались.... Неужели все в отпусках и на каникулах........
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 28.3.2024, 19:29