DJ VK писал(а):Я в своих программах всегда стремлюсь поделить такого вида задачи на две части, в т.ч потому, что работаю часто в паре.
В нашем случае это будет так:
1. Парсер только строит дерево сущностей, которое должно быть внедрено.
например, TTreeNodes c типизированным Record вместо TObject.
Категория, Имя, Описание, Тип.
2. Ядро программы от всех парсеров получает однотипное дерево, и вклеивает в нужые категориии.
Как итог, ядро программы,
которое не я обычно делаю и мне легко говорить, совсем чуть-чуть усложняется.
Но зато парсеры потом создаются очень быстро.
Совсем не забивать свою голову внутренними сущностями программы - вот идеал. И для отладки не нужно тысячу uses=include тянуть. Вообще не нужна планета для этого и все её еже
дневночные дампы и reqiures.
Ну так именно это и сделано. Ядро программы получает дерево из IVectorItemTree, в которых есть только названия категорий (параметры категорий не предусмотрены для импорта вообще) и сами метки каждой из категорий. Причем у меток не обязательно должны быть все атрибуты, а только геометрия, название и описание. А уже потом по этому дереву ядро программы создает недостающие категории, переназначает параметры оформления в соответствии с настройками импорта и запихивает метки в базу.
DJ VK писал(а):Мне предстоит неделю или несколько даже пытаться разобраться в десятках или сотнях абсолютно мне чуждых классов. Да еще и под отладчиком их смотреть. А ведь вместо этой неприятной для меня работы, я мог бы уже грызть дальше Esri Shp и другие, если бы...
я не жалуюсь, это скорее сожаление о довольно сложной и враждебной структуре программы (без поддержки плагинов чуть ли не на любой чих.)
Нет. Вам придется разбираться только в маленьком кусочке классов, которые касаются импорта\экспорта меток. Были бы плагины были бы ровно эти же классы, только еще усложненные необходимостью пробрасывать это все хозяйство между ядром и динамической библиотекой, следить за версиями всего этого и тд.
DJ VK писал(а):ну и неудобно отсутсвие некого unstable репозитория для недоделанных до конца дополнений, которые в конечном итоге, после совместной доработки сообществом, могли бы дополнить таки программу.
Делаете свой форк, а он в любом случае понадобится, и там хоть в одиночку, хоть с помощью всей планеты допиливаете фитчи, а когда они полностью готовы формируете окончательные коммиты и отпраляете пулл-реквест.
DJ VK писал(а):Антибан г**гля кстати работает как часы уже полгода почти. Но "стараниями" сообщества доступен лишь мне одному
Потому и работает до сих пор, что не доступен широким массам. Кому нужно - сам допилит. Я занимаюсь ядром приложения, а не отдельными фитчами рассчитанными на конкретные сервисы.
DJ VK писал(а):Я не оспариваю законность претензий. Я просто говорю, что продуктивнее коллективное взаимодействие без жесткого разграничения прав и обязанностей и взаимовыручка.
Так не бывает. Хотя как я уже писал форк делать придется в любом случае. А в своем форке можете делать все что угодно и никто не запретит и не ограничит.
DJ VK писал(а):Предлагаю уделять немного внимания допиливанию таких вот нововеедений. И часть кода внедрять не коммитами и контролем версий, а Бейонд компэром прямо в папку с отлаживаемым проектом.
Уделяйте. Внедряйте.
DJ VK писал(а):1. обсуждение новых бункций и алгоритмов их работы - багтрекер.
Чего не хватает?
DJ VK писал(а):2. Публикация фрагментов будущего кода - надо площадку.
Уже есть битбукет. С возможность комментирования оналйн и тд.
DJ VK писал(а):3. Публикация модифицированных исходников программы сделанных пользователями - надо площадку.
Тут сложнее. Тут и вопрос доверия к чужим изменениям и к чужому коду. ИМХО для попробовать достаточно выложить собранный exe на любой обменники или даже приаттачить в багтрекере.
В общем вопрос не в технических средствах.
DJ VK писал(а):1. Возможно как-то поддержать ввод доп.настроек пользователем для данного формата импорта ?
Пока никак, точнее там есть какие-то костыли, но именно костыли. Если есть предложения говорите.
DJ VK писал(а):2. Есть конкретный пример TVectorItemTree или парсер где все это уже строится, и можно просто взять и подменить поля конкретных меток?
u_VectorItemTreeImporterXML.pas
DJ VK писал(а):3. Как трактовать MultiPoint и MultiLineString. (Набор точек и набор незамкнутых линий)?
MultiPoint как хотите. Пока такой сущности в САС нету. Можно размножить на несколько отдельных точек.
MultiLineString как мультилинию.
DJ VK писал(а):. Сериализация может и упрощает задачу, но ограничивает область применения - 1 парсер на 1 узкоспецифичный вид GeoJSON. Вручную ведь не сильно медленнее ?
В чем вопрос то?
DJ VK писал(а):5. Как обрабатывать массив массивов в superobject?
Понятия не имею. Спросите у разработчиков superobject