Спасибо за быстрый отклик
vdemidov писал(а):vmax писал(а):1. Метода для получение названия вида экспорта( что вы будете показывать в селекторе выбор типа экспорта? )
Ну я собирался для этого использовать методы PluginAPI. Там у каждого плагина есть Name и Description
Извини, может глупость спрошу, Можно ткнуть пальцем где искать описание методов PluginAPI?
Я увы в Дельфях как слон в помидорах. Java, C, C#, C++, Perl, Fortran а до Дельфи как-то руки не доходили.
Лелею мыслю как бы плагин то реализовать на С/C++ что-бы не разбираться с Дельфями..
Ну да видно проще будет разобраться с Дельфи чем с граблями при мапировании типов данных
и вызывов из дельфей в сишные. К примеру в упор не смог пока понять что такое WideString
и как его мапировать в сишные типы данных. Так что придется для надежности на Дельфях
писать и тут бы сильно помог готовый образчик полной имплементации.
vdemidov писал(а):vmax писал(а):2. Метода FinishExport ( для того что-бы завершить процедуру экспорта - например закрыть файлы индексов и данных )
Такой метод абсолютно бесполезен и вреден. Все закрытия файлов нужно делать в деструкторе объекта с интерфейсом ISimpleTileProcessor.
Ну я бы не был столь категоричен. Классика программирования вполне допускает
переиспользование объектов. Хотя в данном конкретном случае действительно проще рожать новый
инстанс объекта на каждый экспорт а потом его прихлопывать.
Но поскольку из интерфейса не следует однозначного вывода о таком способе работы
потому и появилось желание явного завершения процесса.
vdemidov писал(а):vmax писал(а):Теперь вопросы..к функции ProcessTileATileBuf: Pointer - Что в этом параметре? растр тайла? или бинарные данные - содержимое файла как оно есть на диске?
Содержимое файла в чистом виде.
Согласен нужно в StartExport как-то предавать тип данных. И крайне желательно получать от плагина список обрабатываемых типов. Нового изобретать ничего не будем, возьмем стандартный Content-Type
http://en.wikipedia.org/wiki/Content-Type
Новое придется изобретать даже в этом случае. Content-Type для tne файлов
![Подмигивает ;)](./images/smilies/icon_e_wink.gif)
vdemidov писал(а):vmax писал(а):Очень было бы желательно что бы вы выложили либо пустую рыбу интерфейса
А что, по-вашему, выложено в первом посте. Конечно это первая версия, но сильных изменений не будет.
В посте я вижу только декларацию интерфейсов. Для человека впервые осваивающего Дельфи
это таит массу подводных камней и недосказанностей. К примеру не видно где тут GUID и где Name и версия.
Их тут нет. Они в другом месте. Тогда явно не хватает информации о том как сделать законченный плагин.
Рыба в моем понимании это исходник плагина с неимплементироваными (пустыми) функциями.
В который нужно только дописать конкретную имплементацию.
Либо (по аналогии с явой) базовый абстрактный класс в котором необходимо только
имплементировать недостающие методы.
vdemidov писал(а):vmax писал(а):либо базовую имплементацию простого экспорта. В качестве образчика.
Пока не готово, но скорее всего будет какой-то примитивный экспорт в папку.
А вот за это отдельное спасибо. Просто сгораю от нетерпения
![Подмигивает ;)](./images/smilies/icon_e_wink.gif)
vdemidov писал(а):vmax писал(а):Если как я пологаю AFolderName это директория куда валить выхлоп упаковщика то хотелось бы еще иметь один параметр - имя источника (поддиректории кэша ака SAT, MAP .... итд)
Имя источника это пока больной для меня вопрос. Что отдавать?
Название папки, которое есть сейчас? А вы знаете что там может быть полный путь? А что в перспективе это может быть имя файлового хранилища или строка подключения к базе данных, или скорее всего вообще ничего не быть так как автор плагина-хранилища решит хранить название базы в другом параметре?
Название текстовое, которое показывается пользователю? Так оно может легко меняться.
Сейчас уникальным идентификатором источника является GUID, но не уверен что он вам поможет.
Ну не текстовое название конечно
![Подмигивает ;)](./images/smilies/icon_e_wink.gif)
Имхо ключевое слово здесь "источник" и его имя присутствует как в именах папок так и в именах
zmp файлов. ака SAT, MAP итп. Дефакто это имя (кодовое) уже есть.
Под источником я понимаю исходный источник данных - то откуда эти данные были взяты
а не то где они потом были сложены. Так давайте его и использовать. Чем плохо?
Источник SAT - типа спутниковые снимки от гугла так им и останется даже если придется
менять урлы, гуиды и хранить в разных типах кэшехранилищей.
Имхо ИМЯ источника такая-же характеристика тайла как зум и номера позиции.GUID действительно мало поможет разве что держать еще где-то словарик мапирования
гуидов в имя источника. Но GUID может и поменяться при переходе на другой тип хранилища
а google как был гуглом так и останется
vdemidov писал(а):Да и вообще простой экспорт подразумевает проход по одному источнику. Следовательно это будет одна результирующая папка, а уж ее имя пусть выбирает пользователь. Так что ориентируйтесь, что если AFolderName содержит что-то типа: "C:\Temp\SatYa" создавать файлы SatYa.d00, SatYa.d01, ... и индексный файл SatYa.inx
[/quote]
Такой подход в моем конкретном случае не очень прокатывает.
Попробую пояснить на примере SASПланеты
Если в директории CACHE папочку SAT я поименую как sat_google планета же ее не найдет, потому
что где-то у вас прописано что папка должна называться SAT. Вот и у меня та-же история.
имена файлов прописаны в конфиге.
Т.е. имена файлов привязаны к источникам так же как у вас к источникам привязаны директории.
И полагаться на то что пользователь введет правильные имена очень не хочется. Лишняя головная боль.
Логика экспорта в моем случае подразумевает что экспорт будет всех источников в одну и ту-же
базовую папку (аналог папки CACHE в планете) и тогда имена файлов просто получается не из чего строить.