В связи с началом работы по реализации панельных плагинов в Far.NET вижу, что неплохо бы, наверное, и исторически существующий интерфейс доступа к данным панелей изменить-подрефакторить: 1) для единообразия 2) для производительности 3) для простоты тоже. Мне кажется, это должно быть в целом безболезненно. Но советуюсь - ругайтесь, если чей код это сильно поломает.
Итак:
- IFolder убираем вообще, будет только IFile, который описывает элемент панели.
- соответственно из IFile убирается свойство IFolder Parent
- соответственно в IPanel свойство IFolder Contents (у которого далее надо было вызывать подсвойство-список IList<IFile> Files) заменяем просто на свойство IList<IFile> Contents.
Еще, хотя с этим и не связано:
в публичном интерфейсе есть IMenuItem.FireOnClick() и IPluginMenuItem.FireOnOpen(). Раньше они были нужны для внутренних нужд, сейчас - нет. Убираю из интерфейса, если нет возражений.
Не понял вопрос, если честно. Что значит "по папке нельзя получить список файлов" и "как панель узнает, что ей надо отображать".
Экспериментальный вариант у меня уже работает (и уже с плагин-панелями частично). Все, что кому нужно - все получают без проблем. Какие конкретно операции ты имел в виду, каких у меня нигде нет? Может чего и проглядел.
Что мне еще не нравится в исторической реализации: самая частая операция с панелью (у меня) это получение текущего элемента (чаще всего в ком строках явно или в юзер меню командах). Нелепо, что эта операция всегда обязана конвертнуть в дот нет содержимое *всей* панели только потому, что элемент имеет св-во Parent и оно должно быть либо валидно (то есть содержать все элементы), либо его вообще не нужно (что и предлагается). Я его практически никогда не использую. Если мне нужен список всей панели, я запрошу его у панели, а не у элемента.
К тому же Parent у Parent все равно не устанавливается (как и списки Files у элементов, которые IFolder), то есть то, что исторически реализовано, все равно только частичное что-то и в моей концепции лучше вообще не идти по этому пути и сохранять непротиворечивость данных.
Идея была в следующем:
1. Есть модель файловой системы (IFile + IFolder)
2. Есть объект, отображающий файловую систему (IPanel)
- в фаре они слеплены воедино. Таким образом ими нельзя воспользоваться отдельно (например, я не могу воспользоваться ProxyFTP из своего плагина чтобы скачать какое-нибудь поддерево FTP сервера)
Для дотнет плагинов это хотелось бы сделать более правильным. (Чтоб ProxyFTP.NET предоставлял файловую систему, которая могла бы быть использована отдельно от плагина)
К тому же, утверждения типа "в папке есть файлы" лучше отображаются на объектную модель вещами типа "у объекта "папка" есть свойство "Список файлов"".
Панельные плагины планировалось реализовать так:
плагин присваивает свойство текущей панели Folder, после возврата из плагина фар насинает ходить по файловой системе.
Что мне еще не нравится в исторической реализации: самая частая операция с панелью (у меня) это получение текущего элемента (чаще всего в ком строках явно или в юзер меню командах). Нелепо, что эта операция всегда обязана конвертнуть в дот нет содержимое *всей* панели только потому, что элемент имеет св-во Parent и оно должно быть либо валидно (то есть содержать все элементы),
Есть какие-нибудь препятствие к тому, чтобы реализовать это лениво? То есть чтобы Parent инициалихировался при первом к нему обращении?
Такой подход IFolder+IFile (назовем его провайдером "файловой системы") мне очень близок, и то, что так было задумано, вызывает только уважение. Но это задумывалось "вчера". "Сегодня" есть и другие соображения, причем именно с прицелом на провайдеров.
*) Для простых панельных плагинов (типа тупого списка, где и древовидной структуры то нет) подход с имплементацией провайдера только усложняет дело. Таких микро-плагинов-чисто-списков планирую для себя не один. И будут они элементарно из нескольких строчек на PowerShell, не преувеличиваю.
*) Не скрываю, что при имплементации Far.NET для меня приоритет номер 1 - это применимость к PowerShell (кстати, статистика скачиваний Far.NET и PowerShellFar и говорит, что они вместе и используются в основном). Собственно "плагинирование" Фар для себя я только на PowerShell и планирую. А вот тут и загвоздка с IFolder+IFile имплементацией - в этой версии PowerShell эту модель легко не реализовать. Нельзя создать класс и имплементировать нужные интерфейсы. В следующих версиях вроде планируют, но когда они еще будут? Да и сомнения у меня - если задачка пахнет созданием классов я лучше ее на нормальном языке буду решать, чем на скриптовом. А вот событийная модель имплементации панели (какой она и является по сути в Фар) - в PowerShell реализуется без проблем уже сейчас.
*) Я уже упомянул, что мой прицел тоже на провайдеров данных - только провайдеров PowerShell - пусть дяди их пишут (может и я буду этим дядей тоже), а мы просто это будем использовать. Причем, именно, как и хотелось - такие провайдеры даже вообще не для Фара, просто в Фаре они будут автоматически доступны. Нехитрый демо скрипт у меня уже позволяет ходить в Фаре по:
1) самой файловой системе (провайдер FileSystem), хотя это масло масляное, конечно, но по сетке, например, уже без дополнительного плагина ходим;
2) реестру Windows - опять не нужны плагины на эту тему (провайдер Registry)
3) переменным окружения Windows (провайдер Environment)
4) переменным самой PowerShell (провайдер Variable)
5) функциям PowerShell (провайдер Function)
6) алиасам PowerShell (провайдер Alias)
Это все дяди написали, спасибо им. И еще напишут. И все это будет автоматически работать у нас или с некоторыми косметическими доработками (когда, например, специфика провайдера не совсем 1-1 как файловая система и у него есть что-то, что явно надо использовать, а не автоматом).
И еще плюс подхода без IFolder+IFile - он уже работает :), но версия будет не завтра (хотя скоро), панельки для меня дело новое, так что еще буду разбираться и затачивать все по уму.
mugz wrote:нельзя ли сделать класс на C# - переходник между IFoldr+IFile и моделью PSh?
Можно, но ведь надо СДЕЛАТЬ, а я стараюсь заюзать то, что уже сделано.
Вобщем, я бы сделал чтобы FAR.NET был сосредоточен на меппинге FARAPI в обзектную модель. а PSFAR уже предоставлял удобства для PowerSHell
Ну вообще так оно и будет, просто та *объектная* модель, которая планируется *для начала* будет не IFoldr+IFile, что, кстати, на руку для простых плагинов.
И еще чисто интуиция говорит мне, что сначала надо пойти по пути "событийной реализации". Логика работы Фар под это годами заточена, и значит, такой вход будет вероятно более гладким.
У событийной модели заодно автоматически будет и такая перспективная фича: возможность подписаться на события "чужих" Far.NET панелей, которые, кстати, даже могут разрабатываться с учетом такой возможности.