Структура файла настроек

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

1) правильна ли сама концепция?
2) в каком формате сохранять файл настроек? Смотреть вшитые/библиотечные методы глубокой сериализации объектов в языке в строку или сразу в файл? А если он будет человеконечитаем - то и фиг бы с ним? Или писать свой велосипед/формат?
3) что еще я не учел/не знаю? Задача, судя по всему, наитипичнейшая и 100500 раз всеми решенная, поэтому думаю, должны быть наработанные стандартные ее решения.

0

Сообщение от _Ivana правильна ли сама концепция?

Так в общем то и делают. В большинстве случаев пляска с бубном та еще.

Сообщение от _Ivana Смотреть вшитые/библиотечные методы глубокой сериализации объектов в языке в строку

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

Сообщение от _Ivana что еще я не учел/не знаю? Задача, судя по всему, наитипичнейшая и 100500 раз всеми решенная

Зависит от многих факторов. Например под виндой есть возможность писать все это в реестр средствами API. В некоторых фреймверках, например в VCL есть объектная обертка для ini файла. Сам DFM в котором билдер хранит VCL и FireMonkey формы тоже читаема и писаема средствами фреймверка.
В общем самая большая пляска с бубном заключается в получении этих данных из объектов из которых собрана UI и запись их обратно в объекты. В большинстве случаев либо приделываются к каждому объекту метод сохранить/считать из/в поток настройки, либо делается таблички чего как из объекта каждого задействованного класса читать/писать.

0

Сообщение от Fulcrum_013 Например под виндой есть возможность писать все это в реестр средствами API.

Ну у меня как бы джава, и претензии на запуск везде. Так что надежнее наверное в файлик рядом с jar-ником. Да и методы сериализации наверное есть в платформе. Я конечно могу свой текстовый велосипед наваять, но когда кроме чисел и строк придется сохранять другие иерархичные объекты (а если не придется?), то велосипед треснет по швам. Да и вообще хотелось бы максимально универсальное и расширяемое (в разумных пределах ) решение наваять.

0

Хороших решений нет, зато прочих - до фига. Вот, например: JSON

1

Сообщение от _Ivana Ну у меня как бы джава, и претензии на запуск везде

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

Добавлено через 59 секунд
вот тут расписано как это делается

Добавлено через 5 минут

Сообщение от gazlan Вот, например: JSON

Эта штука хороша при динамической типизации и агрегации. у джавы и то и другое статическое

1

Я тут еще подумал, что изкоробочная сериализация во внутреннее бинарное независимое от платформы/окружения представление - это конечно хорошо, но в моем случае не важна ни скорость ни размер, а поэтому выбор широк, осталось определиться... Но представляю, что самая засада возникнет, когда придется потом доооолго и нууууудно писать перевод объекта сеттингов в гуевое окошко (значения в поля выбора из списков и обратно ). И вот тут то человекоизменяемый формат того же текстового велосипеда option=value или XML/JSON имел бы то преимущество, что его можно править в текстовом редакторе Хотя наверное это не комильфо, и придется таки писать это окно сеттингов с полями...

Или вообще наваять HTML-файл настроек, который будет прямо в браузере открываться и поля выбора из списка с нужными значениями будут сразу, а потом этот HTML парсить в своем приложении Можно будет навести какую-никакую красоту, и не переписывать приложение при каждом добавлении/изменении состава настроек. Но нужен будет браузер

Или вообще сделать обновляемый сайт, на котором будет крутиться эта форма онлайн и кнопка - скачать выбранные настройки в виде файла Но это меня что-то не туда понесло

Хотя из-за моей лени и нежелания облегчать жизнь юзеров я чувствую большой соблазн остановиться на таком варианте без отдельного гуевого окна настроек, с редактированием в текстовом редакторе

0

Если есть удобный xml-парсер проще создать settings.xml

В xml всегда можно что-нибудь добавить, не меняя разбор.

1

Сообщение от _Ivana Хотя наверное это не комильфо, и придется таки писать это окно сеттингов с полями...

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

0

Я тоже думал, что хорошо бы, если платформа имела возможность открывать пользовательские окошки-диалоги для выбора шрифта (как абстрактного объекта - тип/размер/параметры, а не отдельно числом задавать размер, строкой - тип и т.п.), цвета (с палитрой и демонстрацией результата) и т.п. Причем, чтобы это работало на любой ОС где будет запускаться приложение. Надо погуглить, может так оно уже и есть. Тогда я готов подумать, как напихать задание в отдельном окошке однотипных настроек для разных элементов интерфейса.

0

Сообщение от _Ivana 1) правильна ли сама концепция?

Вцелом -- да. В деталях уже надо будет смотреть.

Сообщение от _Ivana 2) в каком формате сохранять файл настроек? Смотреть вшитые/библиотечные методы глубокой сериализации объектов в языке в строку или сразу в файл? А если он будет человеконечитаем - то и фиг бы с ним? Или писать свой велосипед/формат?

XML наше все.

Сообщение от _Ivana 3) что еще я не учел/не знаю? Задача, судя по всему, наитипичнейшая и 100500 раз всеми решенная, поэтому думаю, должны быть наработанные стандартные ее решения.

Поэтому см.п.2

0

Настройки обычно хранят в xml.
Посмотрите класс XMLConfiguration.
http://commons.apache.org/prop... iguration/

0

Сообщение от _Ivana Причем, чтобы это работало на любой ОС где будет запускаться приложение.

Тут гораздо более важна не ось а предоставление языком RTTI (она же reflection). Без рефлексии будет та еще пляска с бубном по описанию того что и как из каждого компонента сохраняемо и редактируемо пользователем

0

Спасибо, сейчас буду смотреть что мне предложит стандартная библиотека по интерфейсу выбора шрифтов/цветов/стилей и т.п.
Но теперь вопрос о тех самых деталях, о которых я писал в первом посте. Язык у меня гораздо ООПее, чем С++, но не настолько ООП, как тот же Smalltalk к примеру. Но раз уж мы в теории программирования - просветите дилетанта - как это красиво организовать в этом вашем ООП. Сейчас у меня есть класс ПарноСкобкоПодсвечиватель, который использует вшитые стили выделения парных и лишних скобок, класс СинтаксоПодсвечиватель, который выделяет разным цветом/жирностью/курсивом различные ключевые конструкции текста, класс НовуюРабочуюОластьСТремяОкнамиСоздавател ь, который назначает окнам размеры и типы шрифтов и т.п. В каждом классе все эти стили и шрифты зашиты жестко, а хочется вынести их в пользовательские настройки. Допустим, я создам новый класс НастройкоХранитель, в котором будет 100500 полей и 100500 методов-геттеров для спрашивания той или иной настройки. Я пока не знаю как мне его делать - абстрактным без создания экземпляра и только со статическими полями/методами - тогда не знаю, засериализуется ли в файл класс без экземпляра, или учиться лепить синглтон? Но допустим я как-то его налепил, этот класс, допустим даже я приделал к нему гуевое окно для задания всех настроек юзером. Когда мои вышеупомянутые 3 класса будут хотеть узнать настройки - они будут вызывать геттеры класса настроек. Но хочется чтобы при апплае (по кнопке в гуе) настроек они тут же применялись и был виден результат, без перезапуска приложения. Кто будет рефрешить настройки ко всем элементам? Чей это метод и чья это ответственность? Как это вообще красиво делается? Или нужно еще 100500 классов и абстрактных фабрик фабрик?...

0

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

0

HighPredator, спасибо, попробую разобраться и составить хотя бы смутное представление

0

пробовал сделать свой велосипед из TOML в итоге вернулся к YAML(да и в ruHaskell он довольно популярен)

0