2011-05-30 3 views
0

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

Что было бы правильным и лучшим способом сделать это? Нужно ли использовать XML-формат? А затем используйте xmlreader для QT? Или мне просто нужно создать свой собственный формат файла и просто использовать поток, чтобы просто прочитать все. Данные в файле должны быть помечены, потому что им нужно будет поместить данные в определенные места на gui. И пользователь имеет возможность динамически создавать поля и вкладки, содержащие определенную информацию.

Если вам нужна дополнительная информация, пожалуйста, дайте мне знать.


короткий пример:

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

ответ

2

В сущности, да, вы создадите свой собственный формат файла, но фактический контент может быть просто XML в любой схеме, в которой вы нуждаетесь. Затем вы можете использовать встроенные возможности обработки XML Qt, чтобы сильно поднять анализ текста (лично я предпочитаю модель DOM, поэтому я использую QDomDocument в качестве базовой точки), и вам просто нужно будет беспокоиться о разборе элементов и от отдельных узлов.

В каркасе Qt есть отличные образцы XML, если я правильно помню, что помог мне сразу же выйти из-под земли. Надеюсь, они помогут!

+0

Да, я смотрел разницу между dom и sax. Какой из них я должен использовать для этой потребности? Кажется, что DOM считывает весь файл в память. И есть третий тип qxmlstreamreader, который они предлагают использовать. Какой из них я должен использовать, если я хочу открыть файл и поместить все в свои пятна на gui, а затем, только если что-нибудь изменится, пользователь попросит сохранить файл. – prolink007

+0

Если вы только читаете пятна местоположения графического интерфейса пользователя, не должно быть проблем с загрузкой данных XML в память.Как я уже сказал, я предпочитаю DOM, вероятно, потому, что это более традиционная модель программирования. Это похоже на алгоритм, тогда как SAX - это шаблон, подобный событию. Это может отлично работать в Интернете, но для локального сохранения настроек это не принесет никакой пользы. – Chris

+0

Я не только читаю места gui. Но содержание этих. Например. Пользователь может создавать вкладки, содержащие текстовые поля редактирования. И эти вкладки связаны с элементами, находящимися в списке. Когда пользователь нажимает на элемент в списке, пользователю будет представлен целый набор новых вкладок. И каждая вкладка имеет некоторые формы редактирования. Файл должен содержать то, что находится в списке, какие вкладки пользователь создал для каждого элемента в этом списке и содержимое каждой вкладки, связанную с вкладкой каждого элемента в списке. Будет ли ваш метод все еще хорошо работать для этой потребности? – prolink007

2

Другое замечательное решение - использовать внутреннюю реализацию базы данных (QSQL поверх sqlite). По сравнению с решением xml он может быть более универсальным (при необходимости обновлять, использовать внешние ключи). Qt имеет некоторые примеры rgeat об использовании этого aas хорошо.

С точки зрения зависимостей, решение XML потребует использования xml и xmlpatterns (если вы хотите проверить материал), тогда как для решения sqlite потребуется QSQL + sqlite-плагин. Я думаю, что sqlite гарантирует атомарность записи, что предотвращает повреждение данных (думаю: пользователь убивает приложение, пока он экономит).

+0

Мне нравится решение SQL с SQlite (простое и быстро развертывается повсюду), основным недостатком является структура без родительского/родительского/дочернего узла XML, но для простой структуры это определенно хороший выбор. Плюс настройки синхронизации/обновления тривиальны, не нужно ничего хранить в памяти, просто извлекайте данные непосредственно в db в любое время. – vrince

+0

@vrince: можете ли вы прочитать мой комментарий ниже на сообщение Криса и рассказать мне, что вы думаете? Спасибо, последний комментарий. – prolink007

+0

@ prolink007 Для пользовательских изменений вам придется отслеживать изменения настроек, чтобы пригласить пользователя на сохранение настроек, а затем обновить соответствующие строки db. Я понимаю, о чем вы просите? – vrince

Смежные вопросы