Есть необходимость написать студию, типа VS.NET. Работа с документами, Doc/View (как в MFC), при этом документы — разных типов и дерево проектов.

Так вот, нужно сделать редкий изврат — одновременное отображение нескольких несвязанных документов в одном окне. Как это сделано в той же студии — они ввели новый ТИП документа — cd. Тип этот — сам мини-проект, внутри xml со ссылками. Меняя документ, меняешь те документы, которые вложены. Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?

Здравствуйте, Аноним, Вы писали:

А>Есть необходимость написать студию, типа VS.NET. Работа с документами, Doc/View (как в MFC), при этом документы — разных типов и дерево проектов.

А>Так вот, нужно сделать редкий изврат — одновременное отображение нескольких несвязанных документов в одном окне. Как это сделано в той же студии — они ввели новый ТИП документа — cd. Тип этот — сам мини-проект, внутри xml со ссылками. Меняя документ, меняешь те документы, которые вложены. Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?

А на сколько серьезный надо сделать проект? И на чем? А то я как-то игрался — сделал каркас SPMDI (Single Project Multi Document Interface) на MFC еще 6.0. Могу показать исходники

C>Здравствуйте, Аноним, Вы писали:

Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?

Smalltalk-80 http://www.rsdn.ru:80/File/4369/mvc_krasner_and_pope.zip

Здравствуйте, Constructor, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>Есть необходимость написать студию, типа VS.NET. Работа с документами, Doc/View (как в MFC), при этом документы — разных типов и дерево проектов.

А>>Так вот, нужно сделать редкий изврат — одновременное отображение нескольких несвязанных документов в одном окне. Как это сделано в той же студии — они ввели новый ТИП документа — cd. Тип этот — сам мини-проект, внутри xml со ссылками. Меняя документ, меняешь те документы, которые вложены. Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?

C>А на сколько серьезный надо сделать проект? И на чем? А то я как-то игрался — сделал каркас SPMDI (Single Project Multi Document Interface) на MFC еще 6.0. Могу показать исходники :shuffle:

Серьезнее не придумаешь. Промышленный комплекс для крупной отрасли промышленности. Надо же что-то за основу брать.

На чем — .NET, поскольку весь юзерский интерфейс пишется на открытых для редактирования end-user'ом скриптах.

Как сделать простой SPMDI и даже MPMDI — не так интересно, поскольку тривиально. Мы застряли именно на той проблеме, о которой я написал: слияние двух документов для совместной визуализации и редактирования. Понимаете: один и тот же документ может быть представлен в виде таблицы, графика и схемы. А его надо скомпоновать с другим таким же документом, поскольку без наложения друг на друга двух графиков пользователям жизнь не мила. А объединять два графика в один документ тоже нельзя — традиционно каждый график обрабатывали как отдельный документ, не поймут-с.

Микрософт поступил хитро — ввел мини-проект. Но им хорошо — у них тип документа один — код, объединения тоже один — диаграмма. А у нас этих типов — 28. И в игру вступает мадам Комбинаторика.

Здравствуйте, <Аноним>, Вы писали:

А>Микрософт поступил хитро — ввел мини-проект. Но им хорошо — у них тип документа один — код, объединения тоже один — диаграмма. А у нас этих типов — 28. И в игру вступает мадам Комбинаторика.
MVC обыкновенный... в чем проблема то? Единственное отличие от класики это то что вид может работать с несколькими контроллерами одновременно.
Еще понадобится некий менеджер который будет отвечать за сопоставление документов и видов.

interface IViewContext : IServiseProvider
{
    ...
}

interface IViewType
{
    IView Create(IViewContext context);
    ...
}

interface IViewInfo
{
    bool IsDefault { get; }
    IViewType Type { get; }
    ...
}

interface IViewManager
{
    //Возвращает список типов видов которые поддерживает данный документ
    //причем именно документ, а не тип документы ибо только в этом случае можно получить список видов для составного документа
    IEnumerable<IViewInfo> GetAvailableViews(IDocument document);
    
    //Создает контроллер и связыает документ с видом
    IController Link(IDocument document, IView view);
}

disclaimer: проектировал на ходу... к именам не придираться.
Создаем 29ый тип документы ака составное документ. Объеденять документы в составной документ можно только если у них есть хотябы один общий вид.
И собственно все. Комбинаторика идет лесом... вернее уходит в динамику где ей самое место.

ЗЫ Еще рекомендую ознакомится с этим: Re[3]: Singleton против static class c# 2

Автор: WolfHound
Дата: 16.05.06

. ИМХО данная концепция для подобных систем просто необходима.

Здравствуйте, WolfHound, Вы писали:

WH>disclaimer: проектировал на ходу... к именам не придираться.
WH>Создаем 29ый тип документы ака составное документ. Объеденять документы в составной документ можно только если у них есть хотябы один общий вид.
WH>И собственно все. Комбинаторика идет лесом... вернее уходит в динамику где ей самое место.

WolfHound, я, с вашего позволения, дизайнер и хочу понять, как это выглядит для юзера для начала. Мое горячее убеждение и железобетонная уверенность — сначала дизайн ЮИ, потом проектирование и код.

Правильно ли я понимаю, что вы предлагаете ввести новый тип документа — "составной"? А как юзверь должен им пользоваться?

Вообще-то, я умозрительно прикидываю, что лучше всего — когда он драг-н-дропом перетягивает документ из дерева проекта на уже открытый документ и тот принимает новые данные. Но это умозрительно. Может кто видел, как такие системы реализованы?

WH>ЗЫ Еще рекомендую ознакомится с этим: Re[3]: Singleton против static class c# 2

Автор: WolfHound
Дата: 16.05.06

. ИМХО данная концепция для подобных систем просто необходима.

Здравствуйте, <Аноним>, Вы писали:

А>WolfHound, я, с вашего позволения, дизайнер и хочу понять, как это выглядит для юзера для начала. Мое горячее убеждение и железобетонная уверенность — сначала дизайн ЮИ, потом проектирование и код.
Только не забывай что можно надизайнить тАкой GUI что реализовать его в коде будет очень сложно. И в этом случа мое железобетонное мнение как программиста нужно пересмотреть GUI ибо как правило можно несильно изменив концепцию GUI избавить программистов от большого колличества проблем.
Короче не забывай консультироваться с архитектором. Ибо если под GUI нельзя подвести чистую и не противоречивую архитектуру то этот GUI никогда не будет польностью реализован и он будет постоянно глючить.

А>Правильно ли я понимаю, что вы предлагаете ввести новый тип документа — "составной"?
Да.
А>А как юзверь должен им пользоваться?
Создает этот самый составной документ.
Открывает его. Открывается редактор составного документа.
Далие драг-н-дропом или чем еще добавляет туда другие документы.
При добавлении первого документа у пользователя спрашивают какой из видов этого документа будет по умолчанию в составном документе.
Если у очередного документа нет вида установленного для данного составного документа по умолчанию спрашивать пользователя действительно ли он хочет добавить этот документ и если да то какой из видов сделать по умолчанию.
Для изменения состава составного документа пользователь щелкает в дереве по этому документу правой клавишей и в контекстном меню выберает редактор составного документа. В прочем тут возможны варианты.
В принципе в контекстном меню для всех документов должен быть список доступных редакторов, а по двойному щелчку должен открыватся редактор по умолчанию.

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

Еще нужно учитывать что могут быть виды которые не поддерживают композицию. Например я не представляю композицию текстовых документов.

А>Вообще-то, я умозрительно прикидываю, что лучше всего — когда он драг-н-дропом перетягивает документ из дерева проекта на уже открытый документ и тот принимает новые данные. Но это умозрительно. Может кто видел, как такие системы реализованы?
И что должно произойти с тем документом что открыли? Вобщем чует мое сердце что тут будут проблемы концептуального характера.

ЗЫ Кстати пригласи сюда архитектора. Демаю ему будет интересно почитать то что тут написано.

Здравствуйте, WolfHound, Вы писали:

А>>Правильно ли я понимаю, что вы предлагаете ввести новый тип документа — "составной"?
WH>Да.
А>>А как юзверь должен им пользоваться?
WH>Создает этот самый составной документ.
WH>Открывает его. Открывается редактор составного документа.
WH>Далие драг-н-дропом или чем еще добавляет туда другие документы.
WH>При добавлении первого документа у пользователя спрашивают какой из видов этого документа будет по умолчанию в составном документе.
WH>Если у очередного документа нет вида установленного для данного составного документа по умолчанию спрашивать пользователя действительно ли он хочет добавить этот документ и если да то какой из видов сделать по умолчанию.
WH>Для изменения состава составного документа пользователь щелкает в дереве по этому документу правой клавишей и в контекстном меню выберает редактор составного документа. В прочем тут возможны варианты.
WH>В принципе в контекстном меню для всех документов должен быть список доступных редакторов, а по двойному щелчку должен открыватся редактор по умолчанию.

Че-та как-то ета... запутанно все. Я бы застрелился с таким интерфейсом.

WH>Еще в дереве можно сделать так чтобы составной документ можно было развернуть (см 2005ую студию) и там бы отображались ярлыки документов которые используются в этом составном документе.
WH>Кстати вот тебе 30й вид документа... ярлык. Тоже может понадобиться.

WH>Еще нужно учитывать что могут быть виды которые не поддерживают композицию. Например я не представляю композицию текстовых документов.

А>>Вообще-то, я умозрительно прикидываю, что лучше всего — когда он драг-н-дропом перетягивает документ из дерева проекта на уже открытый документ и тот принимает новые данные. Но это умозрительно. Может кто видел, как такие системы реализованы?
WH>И что должно произойти с тем документом что открыли? Вобщем чует мое сердце что тут будут проблемы концептуального характера.

Что должно — станет составным, вот что. Аффтоматишески. Это хоть и криво, но лучше создания составного документа руками.

WH>ЗЫ Кстати пригласи сюда архитектора. Демаю ему будет интересно почитать то что тут написано.

Борис! Тебе интересно?

Здравствуйте, <Аноним>, Вы писали:

WH>>Создает этот самый составной документ.
Тут могут быть варианты:
1)Создать как любой другой документ.
В этом случае все происходит как я описал.

2)Перетащить один документ ну другой.
3)Выделить несколько документов и в контекстном меню нажать объединить.
В этих случаях всеравно должен появиться визард который спрашивает имя составного документа и какой вид по умолчанию выбрать.

WH>>Открывает его. Открывается редактор составного документа.
Это можно делать на автомате при создании документа.

WH>>Далие драг-н-дропом или чем еще добавляет туда другие документы.
Это ничем не отличается от твоего днд.

WH>>При добавлении первого документа у пользователя спрашивают какой из видов этого документа будет по умолчанию в составном документе.
Выскакивает модальный диалог в котором один комбобокс и кнопка Ок.

WH>>Если у очередного документа нет вида установленного для данного составного документа по умолчанию спрашивать пользователя действительно ли он хочет добавить этот документ и если да то какой из видов сделать по умолчанию.
Выскакивает модальный диалог в котором один комбобокс и кнопки Ок и Отмена.

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

А>Че-та как-то ета... запутанно все. Я бы застрелился с таким интерфейсом.
Да я бы не сказал. Я уже занимался подобной задачей. Правда у меня все было осложнено тем что я встраивался в студию... и все ее потроха я прополз на пузе
Создавая такую систему с чистого листа я бы многое сделал иначе чем мелкософты.

А>Что должно — станет составным, вот что. Аффтоматишески. Это хоть и криво, но лучше создания составного документа руками.
Еще раз прочитай что я написал в начале предыдущего сообщения.

Ибо если под GUI нельзя подвести чистую и не противоречивую архитектуру то этот GUI никогда не будет польностью реализован и он будет постоянно глючить.

(С) Я
И что еще хуже будет глючить модель...
Смешивание документов и составных документов приведет к сильному усложнению архитектуры или копипасту что тоже мягко говоря не хорошо.