LINUX.ORG.RU

Структура файла настроек java-приложения

 , ,


0

1

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

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


Раньше бы сделал «в лоб» option=value, сейчас бы завел отдельный класс UserSettings и сериализовал бы его в JSON через Jackson. Также в классе модели можно определить дефолтные значения.

mcgeek
()
Ответ на: комментарий от mcgeek

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

Ivana
() автор топика
Ответ на: комментарий от Ivana

Поля в любом случае придется писать не в файле с настройками. Не будете же брать из JSON английские наименования (насколько я понял), если потребуется локализация.

Насчет нечитаемости - возьмите уникальный идентификатор для конкретного ПК и шифруйте/дешифруйте файл DES, если захочется:)

mcgeek
()
Ответ на: комментарий от mcgeek

Да нет, я наоборот не против, чтобы настройки были человекочитаемы и человекоизменяемы в сторонних редакторах - если моя лень и неуважение к юзерам победят и я вместо рисования красивого окна задания сеттингов в своем приложении (с ползунками/списками выбора/блекджеком и анимацией :)) буду заставлять их редактировать допустим текстовый файл настроек, глядя в закомментаренные строки образцов - как надо правильно задавать цвет в формате RGB, какие можно писать имена шрифтов и т.п. :) Идентификаторы полей думаю по-английски можно писать - даже китайцы при желании должны понять :)

Ivana
() автор топика

А что, в Java нет стандартного и рекомендуемого саном ораклом способа хранения настроек???

В Qt, например, есть QSettings...

anonymous
()

Берешь Apache Commons Configuration и используешь любой формат конфигурации по вкусу, которую эта либа поддерживает.

Я обычно использую property-file. Пакую его с дефолтными настройками в jar-ник, а в приложении из classpath его беру. Если надо настройки изменить, просто кладу измененный файл конфигурации в classpath.

Deleted
()

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

Ivana
() автор топика
Ответ на: комментарий от anonymous

в Java нет стандартного

В Java нет вообще ничего стандартного. Даже открыть-записать файл можно 5тью - 6тью разными способами. Один чирижжопней другого.

unt1tled ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.