MVC-подход к разработке пользовательских интерфейсов в Delphi. Часть 2. Списки

Хм, а не проще ли справа использовать список с чекбоксами? ИМХО, будет понятнее без кнопочек добавить/удалить.

Спасибо за статью!

1) Так всё таки, вы пишете этот код (например заполнение ListView в цикле по списку объектов) для каждого списочного контрола формы, или есть свои наработки по уходу от этой рутинной работы?

2) Используете ли гриды для редактирования? Если да, то алгоритм работы аналогичен?

3) небольшой оффтоп, а как в дальнейшем используете этот список присвоенных ролей и прав? Вызываете в начале каждого метода функцию проверки, с именем пользователя и названием/ID метода?

Ну в общем-то подход довольно стандартный для Delphi.
Извините, но очень уж хочется привести сравнение с реализацией на WPF. Тут прямо идеальный случай. Понимаю, что это оффтопик, но может покажется кому-то интересным.

Примерный код окна:
<Window>
<Grid>
<ListBox Name=«lbEmployees»/>
<ListBox ItemsSource="{Binding ElementName=lbWorkers, Path=SelectedItem.Roles}" Name=«lbRoles»/>
<Button Click=«AddRoleClick»/>
<Button Click=«RemoveRoleClick»/>
</Grid>
</Window>

Код приложения:

public sealed class EmployeeRole
{
private string m_Name;

public EmployeeRole(string name)
{
m_Name = name;
}

public override string ToString()
{
return m_Name;
}
}

public sealed class Employee
{
private string m_Name;
private ObservableCollection m_Roles;

public Employee(string name, params EmployeeRole[] roles)
{
m_Name = name;
m_Roles = new ObservableCollection(roles);
}

public ObservableCollection Roles
{
get { return m_Roles; }
}

public sealed override string ToString()
{
return m_Name;
}
}

public partial class MyWindow: Window
{
public static readonly ReadOnlyCollection m_Roles =
new ReadOnlyCollection(
new EmployeeRole[] {
new EmployeeRole(«Бухгалтер»),
new EmployeeRole(«Администратор»),
new EmployeeRole(«Планктон») });

private List GetEployeeList()
{
var result = new List(3);
result.Add(new Employee(«Иванов», m_Roles[0], m_Roles[1]));
result.Add(new Employee(«Петров», m_Roles[1], m_Roles[2]));
result.Add(new Employee(«Сидоров», m_Roles[0], m_Roles[2]));
return result;
}

public MyWindow()
{
InitializeComponent();
lbWorkers.ItemsSource = GetEployeeList();
}

public void AddRoleClick(Object sender, RoutedEventArgs e)
{
var employee = lbEmployees.SelectedItem as Employee;
if (null == employee) return;
var roles = QueryAddRoles();

lbRoles.SelectedItems.Clear();
foreach (var role in roles)
{
employee.Roles.Add(role);
lbRoles.SelectedItems.Add(role);
}
}

public void RemoveRoleClick(Object sender, RoutedEventArgs e)
{
var employee = lbEmployees.SelectedItem as Employee;
if (null == employee) return;
var roles = lbRoles.SelectedItems;
if (null == roles || 0 == roles.Count) return;

foreach (EmployeeRole role in roles)
employee.Roles.Remove(role);
}
}

Практически аналог вашего кода. Кто-то там в комментариях к предыдущему топику говорил про кучу кода.

FSelUserID := -2; // Хочу, чтобы сработал Set-метод
SelUserID := -1; // По умолчанию не выбираю никакого пользователя

Зачем плодить костыли на пустом месте?
Если нужно иметь возможность выполнить некий код минуя проверку, лучше вынеси его в отдельный метод, а не заниматься плясками с бубном.

В старых дельфях (с однозначным номером) все толковые гриды заточены под использование DataSource, фактически таблицы БД. В принципе, можно использовать таблицы без БД (в памяти), есть куча примеров и готовых программ.

Сам я не люблю DataGrid'ы, они для меня недостаточно удобны и слишком сложны. Я делаю примерно как вы, отображение виртуальной таблицы в виде ObjectList'а в в какую-нибудь простую визуальную таблицу. Но ObjectList при этом не простой, в нем есть описание колонок и данных в колонках. И визуальная таблица тоже не совсем простая, умеет привязываться к виртуальной таблице.

1. Master-detail называется такое отношение частей интерфейса, как в вашем примере.

2. Забудьте про with, на них часто бывают проблемы с отладкой, они ухудшают читаемость кода. С ними не всегда понятно какого объекта используется атрибут (в случае с вложенными with, ...).

3. Поддерживаю критику TfmUserRights.FormCreate.

4. (Поэтому в событии OnClick списка lbUsers || TfmUserRights.lbUsersClick ??????). Если я все правильно понял, то:
Вот тут у вас единственна серьезная ошибка, которую я нашел. Вы не сделали обратную синхронизацию, а сделали лишь ложную видимость такой синхронизация. Дело в том, что пользователь может выбрать item не только кликом мышки, но и клавиатурой, и еще каким-то over-хитрым способом, и тогда у вас получится десинхронизация и ложные вводы.

Я так подозреваю, это только потому что у lbUsers компонента (ListView?) нет события onChangeSelection?

P. S. Благодарю за статью, было интересно и познавательно.

1. Спасибо, я в курсе.

2. Да, проблемы с with иногда приводят к трудновыявляемым ошибкам из-за двойственности. Но в примитивных случаях все-равно он удобен. В C# лучше — он выдает ошибку при такой двойственности.

3. Можно было напрямую вызвать SetSelUserID(-1), но при этом FSelUserID желательно все-равно визуально проинициализировать, хоть мы и знаем, что он инициализируется нулем при инстанцировании класса. Просто чтобы было видно, что про инициализацию этого поля мы не забыли.

4. У TListBox событие OnClick срабатывает при любом способе выделения элеиментов, как мышкой, так и клавиатурой. Так что никакой серьезной ошибки тут нет.

На серьезную ошибку статьи не указал НИКТО. В статье не показано, за счет чего обновляется список ролей при добавлении/удалении ролей текущему сотруднику кнопками Добавить/Удалить. При текущем коде роли будут к объектам TUser добавляться и удаляться, но список ролей в GUI не обновится до тех пор, пока вы не переключитесь с одного пользователя на другого. В следующей части статьи я напишу об этом.

>если вы будете выкладывать .exe и исходники
Вам они действительно так уж нужны для понимания того, что я хочу донести? Признаться честно, у меня их нет. Код я сочинил из головы на основе опыта написания подобного кода десятки (а то и сотни) раз. И форму я просто «нарисовал» в Delphi. В проектах такой формы нет. Понятно, что поскольку код не запускался и не тестировался, в нем могут быть неточности. Но я надеюсь, что приведенного кода вполне достаточно, чтобы понять саму идею, которую я пытался донести. Идея состоит в том, чтобы вы всегда работали с моделью, а элементы интерфейса менялись бы в качестве реакции на изменение модели. Я никогда не пытаюсь изменить интерфейс параллельно с моделью и не пытаюсь подменить модель интерфейсом. Интерфейс — это лишь отображение модели.