Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
VD>Замени в своих рассуждениях плоские массивы на вложенные множества и все станет намного понятнее. Пиши так: VD>
VD>А(Б(Г(), Д(), Ж()), В())
VD>
VD>и все будет понятно. Выкинув буквы ты получишь чистые множетсва. VD>
VD>(((), (), ()), ())
VD>
VD>к которым можно обращаться по индексам.
VD>Так доступ к Ж будет выглядеть как: VD>
VD>Views[0][2]
VD>
VD>или: VD>
VD>Б.Ж
VD>
я не понял о чем ты здесь.
У меня есть вопрос по другому примеру:
Но вот в этом примере вообще нельзя однозначно расставить индексы для Б, В и Г:
+-------------------+---------------+-------------------+
| | Б | |
| +---------------+ +
| A | В | Д |
| +---------------+ +
| | Г | |
+-------------------+---------------+-------------------+
Вот допустим, ты прикладник, получивший в наследство такой грид, и тебе надо обратиться к Вью Г.
Ты можешь сказать, что Г имеет индекс [1,2]. А я тебе могу сказать, что Г имеет индекс [0,1,2] или [1,0,2], в зависимости от порядка добавления View. Или даже [1,1,1]. А ведь порядка создания View никто не знает. Ну и как быть? Есть неоднозначности.
[0] [1]
+-------------------+---------------+-------------------+
| | Б [1,0,0]| |
| +---------------+ +
| A[0] | В [1,0,1]| Д [1,1] |
| +---------------+ +
| | Г [1,0,2]| |
+-------------------+---------------+-------------------+
[1,0] [1,1]
AK>>Я боюсь, как бы не пришлось делать для мульти-View Columns и Rows и Spawn, как это намечено в TableLayoutPanel из FW 2.0. VD>С вложенным вариантом проблем не будет. Строки нафиг не упали, а отступы можно сделать просто указав их у контролов реализующих вью.
В общем, с иерархическим построением я согласен. Но пока есть неоднозначности в индексации сложных конструкций.
Здравствуйте, Al-Ko, Вы писали:
AK>я не понял о чем ты здесь.
О исходном примере.
AK>У меня есть вопрос по другому примеру:
AK>Но вот в этом примере вообще нельзя однозначно расставить индексы для Б, В и Г:
AK>
AK>+-------------------+---------------+-------------------+
AK>| | Б | |
AK>| +---------------+ +
AK>| A | В | Д |
AK>| +---------------+ +
AK>| | Г | |
AK>+-------------------+---------------+-------------------+
AK>
Чё ж это нельзя? Только сначала нужно все немножко уточнить. Дело в том, что ты упустил из виду подложку (Б, В, Г). Перерисуем твой пример так чтобы все было видно:
+-------------------+------ Б ------+-------------------+
| | В | |
| +---------------+ +
| A | Г | Е |
| +---------------+ +
| | Д | |
+-------------------+---------------+-------------------+
Где Б — это подложка для (И, Г, Д). И спокойно ответим на вопрос.
Запись в виде множеств будет выглядеть так: (А, Б(В, Г, Д), Е).
Индекс, например, для Г будет такой: View[1][1].
AK>Вот допустим, ты прикладник, получивший в наследство такой грид, и тебе надо обратиться к Вью Г.
Г у тебя — это Д у меня. Так что индекст будет View[1][2].
AK>Ты можешь сказать, что Г имеет индекс [1,2].
После уточнения несомненно.
AK> А я тебе могу сказать, что Г имеет индекс [0,1,2] или [1,0,2], в зависимости от порядка добавления View.
Это если в твоей системе. Я как раз против сквозной индексации.
AK> Или даже [1,1,1]. А ведь порядка создания View никто не знает. Ну и как быть? Есть неоднозначности.
Ну, что-то у тебя вообще какой-то рандом попер.
AK>
AK>+-------------------+---------------+-------------------+
AK>| | Б [1,0] | |
AK>| +---------------+ +
AK>| A[0] | В [1,1] | Д [2] |
AK>| +---------------+ +
AK>| | Г [1,2] | |
AK>+-------------------+---------------+-------------------+
AK>
Еще раз настоятельно рекомендую не думать в терминах плоского или многомерного массива. Это вредно для мозгов.
AK>В общем, с иерархическим построением я согласен.
Ну, уже хорошо. Значит появляется единое мнение.
AK>Но пока есть неоднозначности в индексации сложных конструкций.
Дык на то мы тут и общаемся, чтобы вопросы возникали у нас, а не у тех кто будет потом с этим возиться. Я как раз сторонник того, чтобы ставить на первое метсо не простоту разработки, а простоту последующего использования (даже в ущерб потребляемым ресурсам и скорости (в разумных пределах, конечно)).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
вот теперь у данного View индекс [0,1,2]. А если в пункте 2 добавлять новые в правый вью, то индекс нашего элемента будет [1,0,2]. А если еще учитывать, что в средний вью может добавляться не сразу три, а два вью, и потом один из них включит в себя два, то индекс будет вообще [1,1,1]. Короче, внешний вид один и тот же, а индекс может быть абсолютно разным. Вот только это мне и не нравится в данном подходе. А как с этим бороться — не представляю. Остается только при помощи строк, колонок и объединений? AK>>Но пока есть неоднозначности в индексации сложных конструкций. VD>Дык на то мы тут и общаемся, чтобы вопросы возникали у нас, а не у тех кто будет потом с этим возиться. Я как раз сторонник того, чтобы ставить на первое метсо не простоту разработки, а простоту последующего использования (даже в ущерб потребляемым ресурсам и скорости (в разумных пределах, конечно)).
Я тоже.
Здравствуйте, Al-Ko, Вы писали:
AK>я специально оставил цитирование чтобы было понятнее.
Не надо так делать. Я с успехом могу залесть на сообщение выше.
AK>Я считаю, что далеко не так все однозначно в этом примере. И этот, как ты говоришь, рандом может возникнуть в зависимости от порядка добавления вью.
Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше.
AK>вот теперь у данного View индекс [0,1,2]. А если в пункте 2 добавлять новые в правый вью, то индекс нашего элемента будет [1,0,2]. А если еще учитывать, что в средний вью может добавляться не сразу три, а два вью, и потом один из них включит в себя два, то индекс будет вообще [1,1,1]. Короче, внешний вид один и тот же, а индекс может быть абсолютно разным. Вот только это мне и не нравится в данном подходе. А как с этим бороться — не представляю. Остается только при помощи строк, колонок и объединений?
Т.е. тебя смущает, что одного внешнего вида можно будет добиться разными путями? Дык не стоит этого бояться. Главнео чтобы не путался программист. К тому же хотя они будут эквавалентны по внешнему виду, по функциональности они будут различаться. Ведь при масштабировании они будут вести себя по разнмоу. Одна из панелей ведь обязана быть выровнена влево/вправо, а другая заполнять все оставшееся пространство. И вложенные элементы так же будут вести себя по разному в зависимости от того куда они вложены.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше.
У меня нет проблемы с пониманием иерархического представления нескольких вью
Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Ну да это в конце концов его проблемы. Ведь он может и номер строки в гриде неправильно задать.
Ладно, надо делать, там посмотрим, что из этого выйдет.
Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView.
Здравствуйте, Al-Ko, Вы писали:
AK>Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Согласись, проблем с плоским списком у него будет намного больше.
AK>Ну да это в конце концов его проблемы. Ведь он может и номер строки в гриде неправильно задать.
Как говорится бывает на разные буквы авфафита. Даже на Ё.
AK>Ладно, надо делать, там посмотрим, что из этого выйдет.
Вот это верно!
AK>Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView.
Нет не нужно. Нужно использвать CollectionBase и делать на его основе типизированную коллекцию. Или использовать IList. Если мы переходим на второй фрэймворк, то IList<T>. Кстати, мы таки переходим? Вроде речь шла об этом, и о переходе на SVN...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
VD>>Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше. AK>У меня нет проблемы с пониманием иерархического представления нескольких вью AK>Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Как прикладник могу сообщить, что на мой взгляд вложенные множества гораздо удобнее для понимания и программирования. В этом вопросе я полностью поддерживаю Влада.
Может, я действительно чего-то не понимаю
AK>>Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView. VD>Нет не нужно.
Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д.
VD>Нужно использвать CollectionBase и делать на его основе типизированную коллекцию. Или использовать IList. Если мы переходим на второй фрэймворк, то IList<T>. Кстати, мы таки переходим? Вроде речь шла об этом, и о переходе на SVN...
Так тут все от тебе зависеть. Я бы перешел и туда, и туда. Люблю новшества
Это я не подумал. Хотя если совместить вью и коллекцию в одном флаконе... но это не очень верное архитектурное решение. К тому же не так часто и много прийдется с этими вью возиться.
AK>Может, я действительно чего-то не понимаю
Да вроде все понял.
AK>Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д.
А зачем тогда IViewContainer? Это нужно прямо у вью и делать.
AK>Так тут все от тебе зависеть. Я бы перешел и туда, и туда. Люблю новшества
Ну, тогда ты все доведи до более менее нормального промежуточного состояния, отрапортуй мне и я переведу все сразу и на второй дотнет, и под свина.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AK>>Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д. VD>А зачем тогда IViewContainer? Это нужно прямо у вью и делать.
1) для правильной объектной декомпозиции. Потому что особенности View как контейнера других View являются отдельной, так сказать, темой для разговора. Точно так же, как его особенность осуществлять скроллинг или обработку ввода.
2) VirtualGrid тоже является контейнером View, но не является View. Самое лучшее — реализовать общий интерфейс IViewContainer.
В этот интерфейс будет вынесена свойством коллекция Views и (как ты подметил ) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично
VD>Ну, тогда ты все доведи до более менее нормального промежуточного состояния, отрапортуй мне и я переведу все сразу и на второй дотнет, и под свина.
k
я уже, кстати, пробовал его переводить под Express 2005. Проект компилируется и даже работает!
Здравствуйте, Al-Ko, Вы писали:
AK>В этот интерфейс будет вынесена свойством коллекция Views и (как ты подметил ) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично
Не логично. Не следует мешать функциональность коллекции и хранимых в ней типов. Это чревато проблемами. Я тут как-то допустил такую ошибку, и потом очень долго мучался. В итоге зарефакторил все и разделил коллекцию и хнанимые в ней итпы.
Коллекция должна содержать методы монипуляции со множествами (в ней хранящимися). Но она не должна по совместительству еще быть контейнером и т.п. Ее задачи хранить псписок.
AK>я уже, кстати, пробовал его переводить под Express 2005. Проект компилируется и даже работает!
А с чего бы ему не работать то? Это уж нужно очень сильно нашорудить...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Не логично. Не следует мешать функциональность коллекции и хранимых в ней типов. Это чревато проблемами. Я тут как-то допустил такую ошибку, и потом очень долго мучался. В итоге зарефакторил все и разделил коллекцию и хнанимые в ней итпы.
Может ты не понял?
public abstract class VirtualGridBase:
System.ComponentModel.Component,
IVirtualGrid, IViewContainer
{
...
и
public class GridView: IGridView, IViewContainer
{
...
ведь у нас же коллекция сейчас выглядит так:
public class ViewCollection:IList
{
ArrayList _innerArray;
IVirtualGrid _owner;
public ViewCollection(IVirtualGrid owner)
{
_innerArray = new ArrayList();
_owner = owner;
}
......
а будет так:
public class ViewCollection:IList
{
ArrayList _innerArray;
IViewContainer _owner;
public ViewCollection(IViewContainer owner)
{
_innerArray = new ArrayList();
_owner = owner;
}
......
VD>Коллекция должна содержать методы монипуляции со множествами (в ней хранящимися). Но она не должна по совместительству еще быть контейнером и т.п. Ее задачи хранить псписок.
коллекцию мы не трогаем, а просто приводим вью и ВГ к одному интерфейсу как к сущности, управляющими вложенными вью.
Вообще, если ты помнишь, система сейчас такая:
ВГ содержит коллекцию Вью из элементов типа GridView. При добавлении нового Вью метод Add коллекции обращается к интерфейсу IViewManager. Этот интерфейс реализуется ПАЛ-контролом, который и создает физический Вью (Win32View). Этот физический вью сопоставляется с "виртуальным" GridView, который находится в коллекции.
А теперь, учитывая вложенность GridView, будет происходить все примерно также, но GridView, поскольку сам содержит вложенные вью, будет реализовывать интерфейс IViewContainer, а физический вью, равно как и ПАЛ-контрол, должен реализовывать IViewManager.
Таким образом, управление вью на виртуальном уровне осуществляется ВГ и GridView через интерфейс IViewContainer, а на физическом уровне им занимаются ПАЛ-контрол и зависимый от платформы вью через IViewManager
получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Тогда в коде формы получается примерно такая картина:
Здравствуйте, Al-Ko, Вы писали:
AK>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Я кстати, могу сделать и сериализацию в одну строку, чисто по иерархии, и не делать вью компонентом, но тогда у GridViews дочерние Views будут содержаться не в коллекции, а в массиве. Ну и соответственно траблы, с этим связанные. Нужно тогда будет добавить в методы вью такие методы, как Remove и Add (именно вью, т.к. дочерней коллекции нет, есть только массив).
Но вариант с компонентами мне лично больше нравится.
Здравствуйте, Al-Ko, Вы писали:
AK>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Вовсе не обязательно. Достаточно создать тайп-конвертор возвращающий TypeDescriptor.
AK>Тогда в коде формы получается примерно такая картина:...
Несовсем. Для Вьюх отдельные переменны ненужны. Они могут создаваться прямо при добавлении, а их состояние можно передавать через параметры конструктора.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>Здравствуйте, Al-Ko, Вы писали:
AK>>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
AK>Я кстати, могу сделать и сериализацию в одну строку, чисто по иерархии, и не делать вью компонентом, но тогда у GridViews дочерние Views будут содержаться не в коллекции, а в массиве. Ну и соответственно траблы, с этим связанные. Нужно тогда будет добавить в методы вью такие методы, как Remove и Add (именно вью, т.к. дочерней коллекции нет, есть только массив).
AK>Но вариант с компонентами мне лично больше нравится.
статью... конкретно раздел "Сериализация простых классов". Там подробно написано, как сделать простые классы сериализуемыми в код. Никаких массивов или компонентов для этого ненужно.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
статью... конкретно раздел "Сериализация простых классов". Там подробно написано, как сделать простые классы сериализуемыми в код. Никаких массивов или компонентов для этого ненужно.
я ее прочел, когда она еще не была написана
VD>Вовсе не обязательно. Достаточно создать тайп-конвертор возвращающий TypeDescriptor.
усе ясно. Но как сериализовать вложенные коллекции?
Ведь сам код, генерируемый при сериализации, должен выглядеть так:
_simpleGrid.Views.AddRange(new GridView[]
{
new GridView(new GridView[]
{
new GridView(),
new GridView()
}),
new GridView(new GridView[]
{
new GridView(),
new GridView(),
new GridView()
})
});
Здесь создается у ВГ два дочерних Вью-контейнера, у первого из них создается два окна отображения грида, а у второго — три.
Я специально опустил все другие параметры конструктора GridView. Получается, у GridView для этого случая есть два конструктора:
один:
public GridView(GridView[] views)
{
_views.AddRange(views);
}
и второй пустой, без параметров.
В классе GridView, как и в классе ВГ имеется коллекция Views:
/// <summary>
/// Коллекция дочерних областей вывода грида на экран
/// </summary>
[Category ("GridView")]
[DesignerSerializationVisibility(
DesignerSerializationVisibility.Content)]
public ViewCollection Views
{
get
{
return _views;
}
}
И, наконец, выдержка из тайпконвертора для GridView:
Вот при таком раскладе и получается код сериализации, приведенный выше — я ничего другого не смог придумать.
И если ты в прикладном коде захотел создать какие-нибудь дочерние View, пишешь:
GridView myView = new GridView();
GridView anotherView = new GridView();
myGrid.Views.Views[0].Views[1].AddRange(myView, anotherView);
А вообще, если честно, когда я с этим связался, сдается мне, что эта идея с вложенными Вью очень наворочена и сложна. Теперь для каждого вью нужно проверять, если его коллекция Views пуста, то он работает как окно отображения, а если там есть элементы, то он работает как контейнер. Другая обработка отрисовки, другая работа со скроллингом, со вводом и т.д. Объем работы удваивается, а выигрыша немного. Когда оно все существовало в плоском виде, таких проблем не возникало.
Может подумаем, и еще чего-то придумаем? Например со строками, столбцами и объединением, но так, чтобы все вью находились в одной коллекции при ВГ?
) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично 
