Тип плагинов: Простой экспорт в папку

[vmax]

Ну поверьте, что написав объекты с интерфейсами, которые я описал в заголовочном посте будет очень просто сделать готовый работающий плагин.

В это верю безоговорочно. Да просто. Но ....
Сколько раз придется поднимать диалог выбора директории для экспорта всего кэша всех источников?
Это же банально неудобно будет конечным пользователям.

В моем случае наверное лучше будет использовать простой экспорт в ФАЙЛ а не в папку.
Особенно если вы сможете подставить по умолчанию имя поддиректории источника в качестве имени файла,
а при последующих поднятиях того-же экспорта сразу подставлять уже выбранную в предидущий раз директорию
и новое имя файла. Наверное это решит мои проблемы. Хотя бы с точки зрения минимизации ошибок пользователя
при вводе. Хотя не решит проблем с неудобством многократного повторения рутинной операции для конечного пользователя.

[vdemidov]

Сколько раз придется поднимать диалог выбора директории для экспорта всего кэша всех источников?Это же банально неудобно будет конечным пользователям.

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

В моем случае наверное лучше будет использовать простой экспорт в ФАЙЛ а не в папку.

Да. Привяжитесь, например к индексному файлу и всего делов. Кстати для экспорта в файл походу нужно еще что бы он возвращал список масок для диалога выбора файла и маску файла по-умолчанию.

[vmax]

Сколько раз придется поднимать диалог выбора директории для экспорта всего кэша всех источников?Это же банально неудобно будет конечным пользователям.

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

Вот пытаюсь осмыслить наши с вами обсуждения...
"Я один умный мысль скажу.. Только ты не обижайся.." (c)
Экспорт это экспорт и куда и как складывать полученные тайлы это функционал плагина и знать самой планете
о том куда и как это будет складываться вроде бы и не зачем.
Отсюда напрашивается единый интерфейс экспорта на все случае жизни.
Разница лишь в получении некого адреса (директории, файла, строки коннекта к базе) и только
Причем самой хост программе этот адрес даже и не нужен. Вы его потом все равно скармливаете
плагину.
Зоопарк интерфейсов растет из того что вы пытаетесь интрефейсную часть специфических
для плагина параметров вытащить на уровень хост программы.

Так может имеет смысл рассмотреть вариант единого интерфейса экспорта работающего по
такому сценарию
1. юзер выбрал тип экспорта, набор источников и зумов
2. Хост программа вызывает метод StartExport
3. Выполняя этот метод имплементация интерфейса сама поднимает
собственный диалог какой нужен и запрашивает параметры
специфические для данного типа экспорта (как то диалог выбора имени файла к примеру )
4. Получив параметры и проверив их правильность управление возвращается хост программе
в случае успеха с объектом которому надо скормить файлы либо NULL если юзер вдруг передумал.
5. Дальше если получен инстанс объекта то хост программа скармливает плагину подряд все данные
( ох-хо ну конечно же с указанием ид источника... а как без него )

На мой взгляд такой вариант единого интерфейса экспорта гораздо более органично встроится в
систему чем кучка разных интерфейсов. Да и вам не придется придумывать и устаканивать интерфейсы
на каждый новый тип экспорта..

Ну возможны еще дополнительные методы... типа
Что-бы спросить у интерфейса способен ли он переварить данные из нескольких разных
источников и соответственно показать выбор источников ввиде мультиселекта или селекта по одному.
bool CanHandleMultipleSources();
Возможно захочется еще аналогичный метод для зумов
bool CanHandleMultipleZooms();

Ну вобщем вот такие мысли...

[vdemidov]

Экспорт это экспорт и куда и как складывать полученные тайлы это функционал плагина и знать самой планете о том куда и как это будет складываться вроде бы и не зачем. Отсюда напрашивается единый интерфейс экспорта на все случае жизни.

Единый интерфейс придумать то можно, но есть несколько проблем. Во-первых, плагинам тогда весма много чего понадобиться от хост программы, а, во-вторых, писать плагины даже для простых случаев станет очень сложно.

Зоопарк интерфейсов растет из того что вы пытаетесь интрефейсную часть специфических для плагина параметров вытащить на уровень хост программы.

Я пытаюсь не дать плагинам вообще прямого доступа к интерфейсной части. Тоесть в плагине не должно быть никаких диалоговых окон, месседж боксов и тд. Все взаимодействие с пользователем только через хост программу.
А то представьте как тогда реализовывать список заданий, если каждый плагин будет по своему желанию будет

Выполняя этот метод имплементация интерфейса сама поднимает собственный диалог какой нужен и запрашивает параметры специфические для данного типа экспорта (как то диалог выбора имени файла к примеру )

что из этого за фигня получится?
Вообще в далекой перспективе плагины вполне могут выполнятся в песочнице по типу как это делает Хром или Огнелис. Без какой либо возможности для плагина выдать свое окошко перед глазами юзьверя или обратится не к тому файлу, который выбрал юзьверь.

[vmax]

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

Ну не очень понятно нужна ли в данном случае песочница. Это ж не браузер которому плагины впендюриваются
непонятно кем и непонятно зачем. ИМХО перебор.

Можно привести массу примеров систем где параметры плагины получают
через собственный UI или просто отдавая собственную формочку настроечных параметров хост программе
Вполне жизненный подход. Хотя писание плагинов ессно усложняет.

Есть и другой вариант, можно у плагина запрашивать список необходимых параметров
(Имя, лейбл, типКонтрола, [набор опций(name,value)], [дефолтное значение], [min,max] )
и рендерить это в хост программе... (а-ля проперти едитор )
а потом возвращать полученые от юзера значения плагину.

[vdemidov]

Ну не очень понятно нужна ли в данном случае песочница. Это ж не браузер которому плагины впендюриваются непонятно кем и непонятно зачем. ИМХО перебор.

А думаете тут разработчики плагинов будут писать менее глючные плагины чем, например, Adobe? Или что пользователи будут более разборчивы? А функции тут почти как у браузера. Тот же доступ в сеть.

Можно привести массу примеров систем где параметры плагины получаютчерез собственный UI или просто отдавая собственную формочку настроечных параметров хост программе Вполне жизненный подход. Хотя писание плагинов ессно усложняет.

Именно, что усложняет, поэтому я хочу сделать, как минимум, возможность плагинов без всякого GUI. То что позже появится более универсальный тип плагинов, не значит, что не стоит делать этот более простой.

Есть и другой вариант, можно у плагина запрашивать список необходимых параметров (Имя, лейбл, типКонтрола, [набор опций(name,value)], [дефолтное значение], [min,max] )и рендерить это в хост программе... (а-ля проперти едитор ) а потом возвращать полученые от юзера значения плагину.

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

[vmax]

Терпеливо ждемс когда наступит счастье и в дополнение к декларациям интерфейсов
будет выложена рыба плагина экспорта (желательно в виде проекта в который надо только вписать код методов)
Ну и когда собственно планета будет их поддерживать.