Большая проблема, может быть даже философская

[explorer.85]

max да у меня так как вы написали сейчас все только вот смотрите
что я делаю с вашим сигналом dataChanged только у меня он TaskEdited

Код:

ProjectModel::ProjectModel(Storage *storage, QObject *parent)
    : QAbstractItemModel(parent)
{
    storage_ptr = storage;
    QObject::connect(storage_ptr, SIGNAL(taskEdited()),
                         this, SLOT( dataEdited() ));
}

void ProjectModel::dataEdited()
{
   emit dataChanged(this->index(0,0,QModelIndex()),this->index(rowCount(QModelIndex),0,QModelIndex()));
}

TaskModel::TaskModel(Storage *storage, QObject *parent) :  QAbstractItemModel(parent)
{
    storage_ptr = storage;
    QObject::connect(storage_ptr, SIGNAL(taskEdited()),
                         this, SLOT( dataEdited() ));
}
void TaskModel::dataEdited()
{
   emit dataChanged(this->index(0,0,QModelIndex()),this->index( rowCount(QModelIndex),0,QModelIndex()));
}

это для редактирования.....

для вставки аналогичная схема только с begininsertrows endinsertrows.....

То есть в модели сигналом emit dataChanged(this->index(0,0,QModelIndex()),this->index( rowCount(QModelIndex),0,QModelIndex())); приходится указывать не конкретный индекс для обновления
а весь диапазон индексом модели я правильно вас понял? А это не то же самое что reset()? извиняюсь за может быть дилетантские вопросы конечно...

[UNION labs]

Вот какие мысли по теме родились:
1. Изначально назрела правильная архитектура -> одна модель (класс storage) и два представления (дерево проектов+задач и список задач).
2. Реализовать такую архитектуру средствами model/view фреймворка от Qt сложно (если вообще возможно (избегая дублирования данных и роста сложности кода проекта)... затраты наверняка не окупятся).
  - Как вариант можно реализовать наследника ListView который будет показывать элементы второго уровня дерева
3. По-моему для таких ситуаций целесообразней использовать ItemWidget'ы чем ItemView'ы, т.е. используя классическую схему mvc/mvp а не от Qt.

[explorer.85]

UNION labs: наследника от ListView реализовать..... на такое не способен, и я думаю вряди ктонибудь такими делами на этом форуме вообще занимается (ну я имею ввиду свои вьюхи делает). Наверное создать свое представление из QAbstractItemView но это тоже сложно. А можно ссылку где тролли пишут про itemWidget.  Я первым делом тоже о них подумал но помоему гибкости больше с mvc.

2. Реализовать такую архитектуру средствами model/view фреймворка от Qt сложно (если вообще возможно (избегая дублирования данных и роста сложности кода проекта)... затраты наверняка не окупятся).

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

Вообще пессимистичный у вас пост получился я все таки верю в Qt

[UNION labs]

http://qt.nokia.com/learning/education/course-materials

20 слайд

"Sometimes separating the model from the view is too complex"

[Igors]

Никогда не пользовался MVC (не нужно) и помочь здесь не смогу. Но задачи такого плана встречаются в моей практике часто. По поводу "правильно ли 2 модели" - безусловно правильно.

Представим себе что нет MVC, базы - надо просто это сделать на контейнерах (напр STL). Стопудово задачи храним в отдельном контейнере (вот и модель). Хотя бы потому что возможен вариант когда задача не входит ни в 1 из проектов. О каком "дублировании" данных идет речь? Если я правильно понял, проект хранит ID задач - какое же это дублирование? Да, 2 структуры данных должны быть синхронизированы, но это возникает в любой задаче "выше травы".

Так что смелее  и не позволяйте себя запугать высокопарным фуфлом типа "правильнвя архитектура"  

[UNION labs]

Вообще пессимистичный у вас пост получился я все таки верю в Qt

я же не говорю, что это не реально в принципе реализовать, я говорю о целесообразности затрат (затраченное время/результат).

[explorer.85]

Igors: спасибо, ага почти правильно 2 вектора в одном задачи в другом проекты у каждой задачи есть id проекта к которому она принадлежит, да это и есть моя собственная модель данных, ну плюс обертка из класса storage и методов для доступа к этим данным.Это все отлично. То что сам пишешь всегда понимаешь. А вот дальше когда настраиваешь взаимодействие своей модели Storage и Qt-шных я же свою модель Storage не могу напрямую к QTreeView например прикрутить, потому что у меня нет интерфейса для этого. А есть qabstractitemmodel котороый как раз и позволяет любую модель которую я нафантазирую типа моего Storage, прикрутить к уже реализованной в Qt вьюхе. И все хорошо и все мне нравится но вот есть некоторые моменты которые не понятны.
На данный момент сделал как посоветовыал max но осталась проблема

То есть в модели сигналом emit dataChanged(this->index(0,0,QModelIndex()),this->index( rowCount(QModelIndex),0,QModelIndex())); приходится указывать не конкретный индекс для обновления
а весь диапазон индексом модели я правильно вас понял? А это не то же самое что reset()? извиняюсь за может быть дилетантские вопросы конечно...

Как то это неправильно.. или я неправильно сам понял max-a

UNION labs: А что делать фреймворк не выбирают в моем случае, а самому писать модели представления и контроллеры , вообще нереально.

[m_ax]

Как то это неправильно.. или я неправильно сам понял max-a

Если данные меняются в адапторе минуя представление, то да предётся вызывать reset для модели.
И похоже, что это придётся делать всегда, поскольку обе модели ничего друг о друге не знают.

А как Storage у вас реализован?

[developer]

Попробуй так.
Есть дерево.
        pid      type       name
id 1   0        project    SuperPr
id 2   1        task        Task1
id 3   1        task        Task2
id 4   1        task        Task3
id 5   0        project    SuperPr1
id 6   5        task        Task4

Ето была структура, дерево виглядит так

id 1, pid 0 SuperPr
id 2, pid 1   |__Task1
id 3, pid 1   |__Task2
id 4, pid 1   |__Task3
id 5, pid 0 SuperPr1
id 6, pid 5   |__Task4

Как видиш, мы работаем только с одной моделью. Каждый елемент имеет уникальный идентификатор - ID, поле PID нужно для дереваб есло оно 0 значит ето корень, если не ноль значит ето подкорень.
Теперь тебе нужно только правильно переписать что-то вроде refresh(bool) метода. Если нам нужно дерево - тогда строим дерево по приведеной више структуре з учетом всех PID, если нужни только задачи, значить фильтруем по TYPE=task и выводим просто список

[explorer.85]

developer: пока я пытаюсь осмыслить..... то есть я так понимаю реализовываь вы все это предлагаете  средствами QAbstractItemModel. то есть у нас будет один экземпляр самописного подкласса QAbstractItemModel подключенный одновременно к двум представлениям treeview и tableview? Данные в нем будут организваны по предложенной вами схеме, и будет метод refresh котроый будет менять эту модель превращая ее из списка в дерево и обратно?      
Но тогда придется подключать к этой модели вьюхи попеременно, потому что эта наша модель одновременно не может же находится в двух состояниях и обеспечивать две разные (QTreeView и QTAbleView) вьюхи данными.

Интересна практическая часть приментиельно к моделям Qt

[developer]

Не совсем.

Тебе будет нужно что-то вроде:
1. QVector<MyItem*> items; где MyItem - ето структура типа

class MyItem{
char type;//1- Task, 2 - Project
int id;
int pid;
QString name;
}

2. Лучше использовать QTreeWidget. Поскольку он создаеться из QTreeWidgetItem'ов. А они подходят под задачу лучше всего. Поскольку есть возможность задавать парента
QTreeWidgetItem ( QTreeWidget * parent, int type = Type );

3. Теперь когда используеш refresh(bool) - если true тогда делаем дерево, иначе не делаем дерево, а просто добавляем итемы (как будто все они корневые).

 

[explorer.85]

ВНИМАНИЕ!!! Формулирую впрос еще раз БОЛЕЕ ПОНЯТНЫМ языком

ЗАДАДЧА.
Исходные данные:

Есть две сущности
1. Задача

Код:

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

2. Проект

Код:

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

Эти сущности можно добавлять в  списки

QVector <Task> tasks;
QVector <Project> projects;

Причем
при добавлении Задачи в tasks мы указываем ей ProjectID что указывает
на ее принадлежность к проекту с таким же ProjectID

при добавлении Проекта в projects мы указываем ему ProjectID.

Таким образом получается иерархическая связь на верхнем уровне проекты
на нижнем уровне задачи.
У одного проекта может быть несколько задач.
Задача одновременно может находится только в одном проекте.
НУ вобщем я думаю понятно двухуровневое дерево получается
проекты родители, задачи дети.
-----------------------------------------------------------
Необходимо реализовать GUI для работы  со списками этих сущностей.
-----------------------------------------------------------
Реализовать интерфейс ввода необходимо следующим образом, в двух видах:
1. Двухуровневое дерево проектов и задач.
Проект1
  Задача 1
  Задача 2
Проект2
  Задача 3
Без проекта
  Задача 4

Здесь можно добавить проект, удалить проект, отредактировать проект
Здесь можно добавить задачу к проекту, удалить задачу из проекта, отредактировать задачу.
Проект "Без проекта" отредактировать и удалить нельзя (он создается приложением автоматически
чтобы было куда добавлять задачи во втором виде)


2. Список задач.
 Задача 1
 Задача 2
 Задача 3
 Задача 4

Здесь можно добавить задачу, отредактировать задачу, удалить задачу
При создании задачи в этом виде она попадает в проект "Без проекта"


Вопрос как это сделать с помощью mvc фреймворка qt