Який найпростіший з файлів конфігураційний файл для читання? [зачинено]


13

Поточний файл конфігурації такий:

mainwindow.title = 'test'
mainwindow.position.x = 100
mainwindow.position.y = 200

mainwindow.button.label = 'apply'
mainwindow.button.size.x = 100
mainwindow.button.size.y = 30

logger.datarate = 100
logger.enable = True
logger.filename = './test.log'

Це читається з python до вкладеного словника:

{
  'mainwindow':{
    'button':{
      'label': {'value':'apply'},
       ...
  },
  'logger':{
     datarate: {'value': 100},
     enable: {'value': True},
     filename: {'value': './test.log'}
  }, 
  ...    
}

Чи є кращий спосіб зробити це? Ідея полягає в тому, щоб отримати тип поведінки XML і уникати XML якомога довше. Кінцевий користувач вважається майже повністю комп’ютерним неграмотним і в основному використовує блокнот та копіювальну пасту. Таким чином, стандартний тип "заголовка + змінні" python вважається надто складним.

Користувач манекена редагує конфігураційний файл, програмісти можуть працювати зі словниками. Вкладений словник вибирається для легкого розбиття (реєстратору не потрібен або навіть не може мати / редагувати параметри головного вікна).


11
Абсолютним найпростішим було б побудувати для свого клієнта невелику програму, яка не робить нічого, крім редагування цих конфігураційних файлів.
Патрік Х'юз

11
Найпростіший конфігураційний файл для людей : Do what I want.Це найважче для комп’ютерів, хоча: P
Sjoerd,

@PatrickHughes Я б здогадався, що вже існує. Чи знаєте ви про таку програму. Мені б не хотілося витрачати час лише на «гарненьку друк» простих речей. Проблема полягає в тому, що для додавання невеликих перерв на програму потрібно більше. Я маю на увазі кожен комп'ютер має vim, textedit або блокнот.
Джуха

@sjoerd Це те, що я хотів знати. Чи є алгоритми, які більше на людській мові, ніж програми в цьому сенсі.
Джуха

2
Користувачі можуть зламати що завгодно. Якщо вони збираються редагувати його вручну, будьте готові до підтримкиmainwindow.title =='test"
MSalters

Відповіді:


15

Ви можете використовувати щось на зразок YAML . Ось посилання на приклад:

http://www.yaml.org/start.html

--- !clarkevans.com/^invoice
invoice: 34843
date   : 2001-01-23
bill-to: &id001
    given  : Chris
    family : Dumars
    address:
        lines: |
            458 Walkman Dr.
            Suite #292
        city    : Royal Oak
        state   : MI
        postal  : 48046
ship-to: *id001
product:
    - sku         : BL394D
      quantity    : 4
      description : Basketball
      price       : 450.00
    - sku         : BL4438H
      quantity    : 1
      description : Super Hoop
      price       : 2392.00
tax  : 251.42
total: 4443.52
comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

Ви можете знайти прив'язки Python для цього в PyYAML . Це трохи зручніше для користувачів, ніж JSON (так виглядає ваш другий приклад).


10
YAML - денді, але точно не найпростіший.
9000

1
Я вважав найпростішим у контексті його запитання: "будьте типовими для поведінки XML і уникайте XML якомога довше". Я не впевнений у чомусь простішому, дотримуючись цієї вимоги.
jmq

хм, так це мій перший кодовий блок YAML, якщо я зміню "." і "=" до ":" і втратити афостропи? Є небагато зайвих даних, але тоді користувач повинен залежати від того, які позначення йому найбільше подобаються.
Юха

3
Я досить певні нетехнічні користувачі збираються отримати відступ неправильно - НЕ кажучи вже про більш неясних речах , як >AFTER comments:, а &й *передid001
Izkata

6

Найкраще, що ви можете зробити, це надати макет свого рішення та, можливо, макет з кількох інших рішень, і запитати двох-трьох представницьких користувачів вашої системи. Вони будуть набагато краще говорити вам, що їм подобається, ніж самовибрані люди, які відповідають на запитання на цьому сайті.

Це означає, що для "в основному неграмотних" користувачів я думаю, що формат, який ви показуєте у своєму запитанні, мабуть, найкращий звичайний текстовий формат. Якщо вони справді комп'ютерні неграмотні, ви можете розглянути простий графічний інтерфейс, щоб їм не довелося редагувати конфігураційні файли вручну.


3

Втратити все, що можна втратити. name.name.name=value, кожен на окремому рядку, приблизно такий же простий, як ви можете отримати. Вам не потрібні лапки для синтаксичного розбору, ви знаєте, коли trueбулевий і коли trueрядок, не змушуйте цього говорити "тупий люд". Для рядків, якщо в полі не повинно бути провідних / кінцевих пробілів, зніміть їх самостійно.


3

Уявіть собі китайця, який не знає англійської мови, який намагається прочитати ваш конфігураційний файл. Як варіант, уявіть, що файл конфігурації є арабською мовою (і що ви не знаєте арабської). А тепер запитайте себе, чи справді це читабельно?

Навіть якщо читач не знає англійської мови, він все ще не має уявлення, якщо "logger.datarate = 100" означає 100 символів на секунду, або 100 Гбіт на годину, або 100 курей на метричну тону.

Найбільш читаний людський формат файлів - це двійковий файл із гідним діалоговим вікном / майстром / конфігуратором на основі GUI (з інтернаціоналізацією, довідковою системою тощо).


2

Я з Патріком Хьюзом. Створіть простий додаток для редагування конфігурацій. Сам конфігураційний файл може бути трохи складнішим і може містити атрибути, якими користується редактор (відображуване ім’я, довідковий текст, тип значення, значення min / max тощо).


1
Проблема тут полягає в тому, що програма повинна підтримувати osx, win та ubuntu та мати доступ до файлової системи. Тож моя єдина альтернатива - статичний виконуваний пітон (і wx для рідного вигляду). Або є інші мови? Чи можете ви зробити статичні виконувані файли Java?
Juha

Додаток QT було б простим і конформним рішенням у вашому випадку
Рига

2

Я кажу, що у вас є (файл властивостей) - це найкращий для людини конфігураційний формат. :)

Ось мої аргументи:

  • Файл властивостей - просто пара ключ / значення. Легко читається людиною.
  • Кращий синтаксис, не схожий на xml.
  • Легко вмісти гніздо, з ".", Як у вашому прикладі.
  • Плоска структура дозволяє легко відрізнятися в середовищі, що контролюється джерелом.

Цей останній момент насправді досить важливий. Зважаючи на те, що проекти сьогодні є розділеними на гілки, файл конфігурації може викликати багато болю при об'єднанні гілок. Плоский формат файлу, як файл властивостей, легше об'єднати, ніж файл структури дерева.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.