Есть необходимость написать студию, типа VS.NET. Работа с документами, Doc/View (как в MFC), при этом документы — разных типов и дерево проектов.
Так вот, нужно сделать редкий изврат — одновременное отображение нескольких несвязанных документов в одном окне. Как это сделано в той же студии — они ввели новый ТИП документа — cd. Тип этот — сам мини-проект, внутри xml со ссылками. Меняя документ, меняешь те документы, которые вложены. Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?
Здравствуйте, Аноним, Вы писали:
А>Есть необходимость написать студию, типа VS.NET. Работа с документами, Doc/View (как в MFC), при этом документы — разных типов и дерево проектов.
А>Так вот, нужно сделать редкий изврат — одновременное отображение нескольких несвязанных документов в одном окне. Как это сделано в той же студии — они ввели новый ТИП документа — cd. Тип этот — сам мини-проект, внутри xml со ссылками. Меняя документ, меняешь те документы, которые вложены. Есть ли еще индустриальные продукты, которые можно посмотреть для вправки мозга?
А на сколько серьезный надо сделать проект? И на чем? А то я как-то игрался — сделал каркас SPMDI (Single Project Multi Document Interface) на MFC еще 6.0. Могу показать исходники
Здравствуйте, 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ый тип документы ака составное документ. Объеденять документы в составной документ можно только если у них есть хотябы один общий вид.
И собственно все. Комбинаторика идет лесом... вернее уходит в динамику где ей самое место.
. ИМХО данная концепция для подобных систем просто необходима.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: MVC (Doc/View), MDI, Project
От:
Аноним
Дата:
29.06.06 16:55
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>disclaimer: проектировал на ходу... к именам не придираться. WH>Создаем 29ый тип документы ака составное документ. Объеденять документы в составной документ можно только если у них есть хотябы один общий вид. WH>И собственно все. Комбинаторика идет лесом... вернее уходит в динамику где ей самое место.
WolfHound, я, с вашего позволения, дизайнер и хочу понять, как это выглядит для юзера для начала. Мое горячее убеждение и железобетонная уверенность — сначала дизайн ЮИ, потом проектирование и код.
Правильно ли я понимаю, что вы предлагаете ввести новый тип документа — "составной"? А как юзверь должен им пользоваться?
Вообще-то, я умозрительно прикидываю, что лучше всего — когда он драг-н-дропом перетягивает документ из дерева проекта на уже открытый документ и тот принимает новые данные. Но это умозрительно. Может кто видел, как такие системы реализованы?
WH>ЗЫ Еще рекомендую ознакомится с этим: Re[3]: Singleton против static class c# 2
Здравствуйте, <Аноним>, Вы писали:
А>WolfHound, я, с вашего позволения, дизайнер и хочу понять, как это выглядит для юзера для начала. Мое горячее убеждение и железобетонная уверенность — сначала дизайн ЮИ, потом проектирование и код.
Только не забывай что можно надизайнить тАкой GUI что реализовать его в коде будет очень сложно. И в этом случа мое железобетонное мнение как программиста нужно пересмотреть GUI ибо как правило можно несильно изменив концепцию GUI избавить программистов от большого колличества проблем.
Короче не забывай консультироваться с архитектором. Ибо если под GUI нельзя подвести чистую и не противоречивую архитектуру то этот GUI никогда не будет польностью реализован и он будет постоянно глючить.
А>Правильно ли я понимаю, что вы предлагаете ввести новый тип документа — "составной"?
Да. А>А как юзверь должен им пользоваться?
Создает этот самый составной документ.
Открывает его. Открывается редактор составного документа.
Далие драг-н-дропом или чем еще добавляет туда другие документы.
При добавлении первого документа у пользователя спрашивают какой из видов этого документа будет по умолчанию в составном документе.
Если у очередного документа нет вида установленного для данного составного документа по умолчанию спрашивать пользователя действительно ли он хочет добавить этот документ и если да то какой из видов сделать по умолчанию.
Для изменения состава составного документа пользователь щелкает в дереве по этому документу правой клавишей и в контекстном меню выберает редактор составного документа. В прочем тут возможны варианты.
В принципе в контекстном меню для всех документов должен быть список доступных редакторов, а по двойному щелчку должен открыватся редактор по умолчанию.
Еще в дереве можно сделать так чтобы составной документ можно было развернуть (см 2005ую студию) и там бы отображались ярлыки документов которые используются в этом составном документе.
Кстати вот тебе 30й вид документа... ярлык. Тоже может понадобиться.
Еще нужно учитывать что могут быть виды которые не поддерживают композицию. Например я не представляю композицию текстовых документов.
А>Вообще-то, я умозрительно прикидываю, что лучше всего — когда он драг-н-дропом перетягивает документ из дерева проекта на уже открытый документ и тот принимает новые данные. Но это умозрительно. Может кто видел, как такие системы реализованы?
И что должно произойти с тем документом что открыли? Вобщем чует мое сердце что тут будут проблемы концептуального характера.
ЗЫ Кстати пригласи сюда архитектора. Демаю ему будет интересно почитать то что тут написано.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: MVC (Doc/View), MDI, Project
От:
Аноним
Дата:
29.06.06 18:03
Оценка:
Здравствуйте, 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 никогда не будет польностью реализован и он будет постоянно глючить.
(С) Я
И что еще хуже будет глючить модель...
Смешивание документов и составных документов приведет к сильному усложнению архитектуры или копипасту что тоже мягко говоря не хорошо.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн