Import As Open

[Bepec]

Кхм, выражаю своё недоумение "пустым" проектом.

В любом IDE/редакторе мне даются исходные данные. Как то пустой холст/модель/данные. И да, необязательно знать где они на диске

И по поводу импорта - я так понимаю, вам необходим не импорт данных. А скорее вам необходимо провести операцию над данными в файле и уже результат получить. И это уже вопрос не сериализации и не хранения. Это уже повод для отдельной утилиты / класса.

Как говорится разделяйте суп и мух. Импорт данных - отдельно. Работа и преобразование данных - отдельно.

[schmidt]

Выходит Вам с исходными текстами надо работать, а знать где они находятся на диске и как они сложены в фолдерах необязательно?

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

Большинство пользователей вряд ли будут настраивать параметры импорта каждый раз. Скорее всего они просто будут пропускать это назойливое диалоговое окно, не глядя. Так стоит ли заставлять человека просто лишний раз нажимать "Enter"? Программа должна просто работать, задавая минимум вопросов. Пусть она импортирует все возможные данные без потерь, дав опытному пользователю возможность впоследствии выбросить ненужное или изменить/пересчитать определенные данные. Пользователи тихо ненавидят, когда их допрашивают на каждом шаге посредством диалоговых окон Решать за пользователя, что ему нужно, а что нет, конечно, не стоит, но это не повод устраивать пользователю допрос на каждом шагу

[Igors]

Импорт данных - отдельно. Работа и преобразование данных - отдельно.

Именно так и сделано сейчас Проблема в том что ф-ционал импорта (диагностика, исправление ошибок, разбиение и др) оказывается необходимым и для нативных файлов данных.

Программа должна просто работать, задавая минимум вопросов.

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

[Igors]

Сделал изменив/дополнив сериализацию. Выглядит так: если задана "запись с проверкой", то

- часть сериализуемых данных копируется
- из этой копии создаются структуры  данных для ф-ционала импорта
- выполняется ф-ционал и результат конвертируется обратно в копию
- копия сериализуется

При этом создавать/удалять объекты я не могу, это для нативных файлов не поддерживается.
Впечатление элегантности это конечно не производит, но лучшего не нашел

[schmidt]

Но все-таки давайте ближе к делу.

Давайте

Проблема в том что ф-ционал импорта (диагностика, исправление ошибок, разбиение и др) оказывается необходимым и для нативных файлов данных.

Это говорит о том, что код/функционал, который требуется в нескольких местах стоит выделить в отдельные  независимые методы. Иными словами, если у вас есть солёный борщ и несоленая каша, лучшим вариантом будет взять чистую соль с полки и посолить кашу, чем вливать в нее борща Пусть у вас будет пара-тройка функций с именами а-ля _validateDataIntegrity(), _fixInternalRelations(), _splitPolygons() , которые вы будете использовать независимо как в процедуре открытия нативных файлов так и в процедуре импорта сторонних файлов. По-моему так будет проще и логичнее, чем тащить нативные файлы через чужеродную им процедуру импорта

[Igors]

Это говорит о том, что код/функционал, который требуется в нескольких местах стоит выделить в отдельные  независимые методы.
..
Пусть у вас будет пара-тройка функций с именами а-ля _validateDataIntegrity(), _fixInternalRelations(), _splitPolygons() , которые вы будете использовать независимо как в процедуре открытия нативных файлов так и в процедуре импорта сторонних файлов.

Ну если бы все было так просто (выделить неск ф-ций), то вряд ли у меня бы возникли проблемы 

По геометрии мой формат близок к тому что используется в OpenGL, том же Qt3D и во многих др местах. На рендере все выходит хорошо, но, к сожалению, он никак не подходит для каких-то операций перестройки модели, обнаружения ее дефектов и.т.п. Ну вот напр простейшая модель: кубик, 6 граней, 8 углов, какие могут быть проблемы? Дело в том что точек (вертексов) в нем совсем не 8, а 24. Пытаться что-то с такой моделью делать - обречено, т.к. все время будем натыкаться на проблему "а какая точка?". Приходится перегонять в др структуры данных, что тянет не одну тысячу строк. И.т.д.

Иными словами, если у вас есть солёный борщ и несоленая каша, лучшим вариантом будет взять чистую соль с полки и посолить кашу, чем вливать в нее борща

Давая такие простые-цветистые советы может стоит подумать - а человек действительно этого не знал (ну никак не мог догадаться)?. В общем, тлетворное влияние "вопросов новичков"

[schmidt]

Если я правильно понял, то у вас имеется в первую очередь "родной" формат, описывающий геометрические модели, к нему написаны функции сериализации/десериализации, в этом формате, собственно, и хранятся данные в native-файлах программы. Но беда его в том, что он плохо приспособлен для выполнения операций над моделями, такими как проверка на корректность, преобразования, расчеты, и.т.п. Для этого вы вводите в программу "оперативный" формат - создаете на основе native-формата дополнительные структуры данных, с которыми можно легко проводить различные операции. Это вполне логичныо

Беда в том что "промежуточный формат" содержит раз в 10 меньше данных чем родной.
...
пользователь теряет 90% родных данных - ну и законно недоволен.

Проблема, вероятно, в том, что вы безвозвратно отбрасываете 90% данных при переходе в "оперативный" формат. Что если реализовать функции преобразования модели из формата хранения в оперативный и обратно без потерь данных? Тогда вы сможете читать нативный файл с моделями, сериализованными в формата хранения, затем преобразовав их (без потерь) в оперативный формат, проверить на корректность, провести еще какие-то необходимые операции, а когда придет пора сохранить файл - снова преобразовать модели в "неповоротливый" формат хранения и сериализовать в файл. А импорт из чужих файлов можно сделать "как душе угодно", раз вашего "родного формата" в чужих файлах нет

[Igors]

Что если реализовать функции преобразования модели из формата хранения в оперативный и обратно без потерь данных?

А что здесь значит "без потерь"? Добавить все данные нативного формата в оперативный? Это никак не годится т.к. число нативных данных огромно. По существу сейчас я сделал так:

- из объекта в памяти выделить те данные что нужны оперативному формату
- создать на их основании оперативные/промежуточные данные и выполнить действия над ними
- перевести назад в нативный и сериализовать

Заметим что это "для объекта в памяти" и действия производятся во время сериализации. А иначе, читая нативный файл я должен что-то делать с большинством данных которые в оперативный формат не входят - но куда я их дену?

Др проблема в том что диагностика может потребовать создания/удаления объектов, но это недопустимо на фазе сериализации

[schmidt]

Это никак не годится т.к. число нативных данных огромно.

Как вариант - представить оперативный формат как расширение нативного, чтобы избежать ненужного копирования. То есть сделать так, чтобы к нативному формату "наращивались" оперативные данные. А после ряда модификаций оперативных данных осуществлять вызов некого syncData(), применяющего изменения оперативных данных к "нативной" части. Получилось бы что "расширенный" формат объединял бы в себе нативные и оперативные данные.

[Igors]

Как вариант - представить оперативный формат как расширение нативного, чтобы избежать ненужного копирования. То есть сделать так, чтобы к нативному формату "наращивались" оперативные данные.

Ну а смысл этого агрегата? Если объект (нативные данные) загружается, то он фиксируется в списках объектов, резолвятся его парент и чилдрены и.т.п. Создавать еще какую-то др загрузку (которая живет без всех обвязок) минимум накладно (если вообще реально). С др стороны в нативных данных есть все, так чего спешить с созданием оперативных? Вот и получается

- загрузить нативные данные (можно втихаря, юзверю не показывать)
- сериализовать их, на ходу создавая оперативные
- удалить нативные данные (это конечно имеется)

Тут правда, undo путается под ногами