Re[13]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 07.09.05 15:45
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Препдложи, плиз более подходящий формат, и попробуй обосновать этот выбор. Потом опиши что нужно предпринять для реализации твоего решения.


Тебе описали уже более подходящий формат. Я имел дело с XML языками. Поверь мне, даже Oberon лучше XML языка.
Re[14]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 16:13
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:


ПК>
ПК>Opera Preferences version 2.0
ПК>; Keyboard input specification file for Opera 7.0
ПК>; This file is stored in UTF-8 encoding

ПК>[Version]
ПК>File Version=1

ПК>[Info]
ПК>Name=Opera Standard
ПК>Description=Opera Standard Keyboard setup
ПК>Author=Opera Software ASA
ПК>Version=1

ПК>[Application]
ПК>Platform Windows-Unix-QNX, h ctrl    = Hide Opera
ПК>ContextMenu                          = Show context menu
ПК>Enter ctrl                           = Wand
ПК>Platform Mac, Enter meta             = Wand
ПК>c ctrl                               = Copy
ПК>c ctrl shift                         = Copy to note
ПК>v ctrl                               = Paste
ПК>v ctrl shift                         = Paste to note
ПК>d ctrl                               = Paste and go
ПК>d ctrl shift                         = Paste and go
ПК>x ctrl                               = Cut
ПК>z ctrl                               = Undo
ПК>y ctrl                               = Redo
ПК>z ctrl shift                         = Redo
ПК>y ctrl shift                         = Undo
ПК>a ctrl                               = Select all
ПК>u ctrl                               = Clear
ПК>Ins                                  = Toggle overstrike
ПК>Del                                  = Delete
ПК>Platform Windows-Unix-QNX, Backspace = Backspace | Back
ПК>Platform Mac, Backspace              = Backspace | Delete | Back
ПК>


Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?

С уважением, Gleb.
PS: написал за пять секунд что смотрел на твое сообщение. Возможно, если подумать, то можно придумать еще кучу вопросов.
Re[15]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 16:19
Оценка:
А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.

С уважением, Gleb.
Re[15]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 07.09.05 16:57
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?


Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ... Скажите честно, вы руками писали xml конфиг?
Re[16]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 07.09.05 17:07
Оценка: +3
Здравствуйте, Quintanar, Вы писали:

Q>Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ... Скажите честно, вы руками писали xml конфиг?

Собственно не только я. У меня и пользователи(IT отделы клиентов) редактируют xml налево и направо. И как-то на незнание не жаловались. И кстати, пользуюсь я такими конфигами еще с 2000 года. Так что за пять лет жалобы должны были бы появиться.

С уважением, Gleb.
Re[16]: XML vs рукописный формат для конфигов
От: ArtemGorikov Австралия жж
Дата: 07.09.05 17:23
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Если правильно писать — не больше одного копирования. А если писать еще

C>правильнее, и использовать строчки (flex_string'например) со счетчиком
C>ссылок — вообще копирований не нужно будет.
При использовании строк со счетчиком ссылок, будет все-таки одно копирование. В CAtlString счетчик есть, а flex_string — он входит в состав boost? Вообще меня CString полностью устраивает: не надо писать идиотских .c_str() каждый раз, когда передаешь сишную строку в функцию.


C>Ну да, но вопрос "писать свою _библиотеку_, или взять готовую" вообще

C>почти всегда разрешается в пользу готовой либы.
Я бы сказал 50/50. Есть куча уважаемых коммерческих либ, внутри которых вообще лучше не смотреть, чтобы кошмары ночью не снились В таких случаях лучше понять общую идею и сделать все правильно, чем править чужие баги, которые будут возвращаться снова и снова с каждым новым апдейтом. Если есть подходящая либа в бусте, тогда согласен на 100%.


C>Чуть-чуть изменить грамматику, ну примерно так:

C>
C>rule<> header=....; //Правило для заголовка
C>rule<> csv_file=header << ...; //И так далее
C>


>> а потом записи читались наоборот снизу, т.е. 1 запись уже последняя

>> строчка в файле?

C>Использовать деку вместо вектора и пихать строчки не push_back'ом,

C>push_front'ом.

Т.е. чтобы прочесть 1 запись в реверсивном файле, надо сначала запихать его всего в память? Это тормозное и неприемлемое решение уже для файлов размером в десять метров.



C>Зачем? Если потребуется что-то уж очень нестандартное — то просто

C>пишется custom action, который вставляется как обработчик определенной
C>строки. Более того, в Spirit'е есть еще другой монстр под названием
C>Phoenix. В нем можно писать вот так:
C>
C>    int init[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
C>    vector<int> c(init, init + 10);
C>    typedef vector<int>::iterator iterator;

C>    for_each(c.begin(), c.end(),
C>        locals<int, char const*>(0, "...That's all\n")
C>        [
C>            for_(loc1 = 0, loc1 < arg1, ++loc1)
C>            [
C>                cout << loc1 << ", "
C>            ],
C>            cout << loc2
C>        ]
C>    );
C>

C>Это очень интересно выглядит, когда встраивается в качестве
C>семантических действий прямо в грамматику. Но обычно это уже слишком
C>экстремально — проще написать обычный отдельный функтор.

Меня аж в дрожь бросило Экстремально, впечатляет. А как быть, когда не известно заранее, будет эта строка вообще и если будет то где?
Re[15]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 02:29
Оценка:
GlebZ,

> Судя по всему это кастомный формат.


Нет, это .ini-файл.

> И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'.


Не нужно. Таких символов нет ни в названиях кодов клавиш, ни в названиях команд.

> А кодировка определяется по строке с комментарием?


Нет, она всегда UTF-8.

> А как работает whitespacing?


Так же, как во всех .ini-файлах.

> А если у меня значение начинается с пробела?


Оно не может.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[16]: XML vs рукописный формат для конфигов
От: Павел Кузнецов  
Дата: 08.09.05 02:31
Оценка: -1
GlebZ,

> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.


Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[15]: XML vs рукописный формат для конфигов
От: ArhAngelVezel Россия  
Дата: 08.09.05 04:43
Оценка:
Здравствуйте, GlebZ, Вы писали:


GZ>указать перевод строки или символ '=' или символ '|'.


так же как ты в xml будешь париться с символами '>' '<' '"'
нет универсального языка, в котором не было бы таких приколов.
Лично я начал пользоваться xml только когда перелез на .net ... не потому что это круто, а потому что я могу из данного xml десерилизовать классы всего одной строкой кода... удобно ...
Re[15]: XML vs рукописный формат для конфигов
От: FDSC Россия consp11.github.io блог
Дата: 08.09.05 05:35
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Странно. Почему ты решил, что я не хочу изучать какой-то класс? Да может, я сам его и написал когда-то, или уже пользовался им в похожих задачах.


Мне просто показалась, что тебе лень. Видимо, я ошибся.
Re[16]: Программирование стало более высокоуровневым?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.09.05 08:14
Оценка: +1
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>так же как ты в xml будешь париться с символами '>' '<' '"'


Зачем с ними париться? Там есть стандартные entity для них.

AAV>Лично я начал пользоваться xml только когда перелез на .net ... не потому что это круто, а потому что я могу из данного xml десерилизовать классы всего одной строкой кода... удобно ...


Так в том то вся и фишка, что вокруг XML есть масса готовых технологий.
... << RSDN@Home 1.2.0 alpha rev. 610>>
AVK Blog
Re[16]: XML vs рукописный формат для конфигов
От: GlebZ Россия  
Дата: 08.09.05 16:08
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Нет, она всегда UTF-8.

Это уже ограничение Радостно видеть что ограничение документировано(строкой комментария).

Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl. Или сделаю то же самое для Platform Windows-Unix-QNX, Backspace. Это ведь уже семантика реализованная теми ребятами которые писали Opery, а не Windows. Следовательно, если введены правила, с которыми могут быть введены ограничения, то документированы ли они?
В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:
1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:

[Application]
ContextMenu = Show context menu

Ты можешь понять из текста, что это такое?

2. Существуют попутные технологии, которые могут описать семантику.
Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

С уважением, Gleb.
Re[17]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,


>> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.


ПК>Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.


Описание только пример. А расирений может быть куча. Например, сюда же можно добавить описание контекстного меню (иерархического). Да и описание может задаваться пользователем.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, GlebZ, Вы писали:


GZ>>Судя по всему это кастомный формат. И скажи мне как пользователю, что делать если мне нужно в тексте указать перевод строки, или символ '=' или символ '|'. А кодировка определяется по строке с комментарием? А как работает whitespacing? А если у меня значение начинается с пробела?


Q>Ну да, конечно. Люди 10-тилетиями пользуются такими конфигами, и тут приходите вы ...


Люди еще тысячилетиями пользовались кмаенным топором. Так что это не аргумент.

Q> Скажите честно, вы руками писали xml конфиг?


Да, в VS2005. Как и любой другой понимающий ХМЛ редатор она позовляет очень просто редактировать ХМЛ и проверять его вреность. Плюс можно сгенерировать по ХМЛ-ю схему (одним нажатием кнопки). Вот, например, схема для этого конфига:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="Shortcuts">
        <xs:complexType>
            <xs:sequence>
                <xs:element maxOccurs="unbounded" name="Shortcut">
                    <xs:complexType>
                        <xs:attribute name="Key" type="xs:string" use="required" />
                        <xs:attribute name="Action" type="xs:string" use="required" />
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>


С этой схемой при редактировании будет еще и комплит ворд работать не говоря уже о автоматической проверки синтаксиса. Для такой примитивной задачи это может и не обязательно, но если формат посложнее, то можно сэкономить много времени и нервов. Причем как своих (разработчика), так и потребителя.

Собственно далее элементарно делается визуальные редакторы. И т.п., и т.д.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка: -1
Здравствуйте, Павел Кузнецов, Вы писали:

>> Препдложи, плиз более подходящий формат,


ПК>
ПК>Opera Preferences version 2.0
...
ПК>Platform Windows-Unix-QNX, h ctrl    = Hide Opera
ПК>c ctrl shift                         = Copy to note
ПК>v ctrl                               = Paste
ПК>


Начнем с того, что это не собственный формат о чем тут говорил Quintanar. Это классический инифайл. Просто он плохо для этой задачи подходит и поэтому выглядит как полная задница.

Ну, а продолжим тем, что читать его значительно сложнее. Еще догадаться нужно что справа, что слева. Ну, а "Platform Windows-Unix-QNX, " чистейший левак. В ХМЛ-е бы можно было просто ввести атрибут или тег перечисляющий поддерживаемые платформы.

>> и попробуй обосновать этот выбор.


ПК>Ничего, специфичного для XML в твоем конфиге не используется, XML является только замусоривающей "обвязкой" вокруг твоего собственного формата.


ХМЛ это унивирсальный формат. Ему "специфичность" просто не нужна. Им что хочешь описать можно. Тем он и замечателен.

ПК> В случае выше оставлен необходимый и намного более читабельный минимум в виде собственного формата, без дополнительного мусора из тегов.


Что же в нем читабельного? Ни фига не ясно что это и зачем. Ты бы хоть "ИМХО" добавил бы.

>> Потом опиши что нужно предпринять для реализации твоего решения.


ПК>Не больше, чем в случае использования XML.


Да, больше. Но дело даже не вэтом. Еще раз напомню, что речь шала о собственном да еще и предлагалось его с помощью Яка/Лекса парсить.
Инифайлы довольно убогий формат. Пока их хватает конечно можно пользоваться и ими, но дальше начинаются извращения. Писать собственный формат для подобных случаев, по-моему, не очень разумно. И ХМЛ тут подходит просто замечательно.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>На самом деле, имхо, здесь два языка: первый -- XML со своими заморочками, а второй -- возможность опеределять комбинацию клавиш в одном атрибуте Key, разделяя названия с помощью вертикальной черты.


Два. Только конечно второй язык не определяет шорткаыт (это слишком простая вещь). Воторой язык это семантика данного DSL описывающего конфигурацию клавиатуры. Описание шортката всего лишь его составная часть.

E> Причем никакой XML редактор не оградит незадачливого пользователя от возможности написать Key="Shift+Up" или Key="Shift,Up" или Key="Shift-Up".


E>Уж если использовать XML для описания всего языка, то нужно было бы что-то вроде:

E>
E><?xml version="1.0" encoding="utf-8" ?>
E><Shortcuts>
E><Shortcut Key="Up" Shift="on"                Action="CaretViewLineUpExtend" />
E><Shortcut Key="Down" Shift="on"              Action="CaretViewLineDownExtend" />
E><Shortcut Key="Back" Alt="on" Shift="on"     Action="Redo"/>
E></Shortcuts>
E>


Можно и так. Разница не велика. Мой вариант мне нравится больше.

E>Но так, имхо, уже гораздо менее читабельно.


Мне тоже так кажется.

Собственно если вернуться к исходному вопросу, то согласись читается мой формат довольно хорошо. Его поддержку мне сильно упростило то что я использовал парсеры и другие фичи ХМЛ-я. Плюс не потребовалось долго думать о синтаксисе, так как ХМЛ его почти полностью определяет.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Тебе описали уже более подходящий формат. Я имел дело с XML языками. Поверь мне, даже Oberon лучше XML языка.


Сдается мне, что ты сейчас необъективен.

И главное, что ПК предложил точно такой же стандартный формат. Ты же предложил разрабатывать собственный с помощью Яка. Так что это можно расценивать как отказ от твоих же слов.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: XML vs рукописный формат для конфигов
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.05 16:13
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

GZ>>указать перевод строки или символ '=' или символ '|'.


AAV>так же как ты в xml будешь париться с символами '>' '<' '"'


&lt; &gt; или CDATA и никаких проблем. А вот что делать если нужно список создать, или не дай бог иерархию? Вот, например, во что превращаются инифайлы когда в них запихивают более лсожные конструкции:
cm_VisFlatInterface=2905;Interface: Flat/normal mode

(это из TOTALCMD.INC).
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: XML vs рукописный формат для конфигов
От: Quintanar Россия  
Дата: 08.09.05 16:22
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Павел Кузнецов, Вы писали:


ПК>>Нет, она всегда UTF-8.

GZ>Это уже ограничение Радостно видеть что ограничение документировано(строкой комментария).
GZ>Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl. Или сделаю то же самое для Platform Windows-Unix-QNX, Backspace. Это ведь уже семантика реализованная теми ребятами которые писали Opery, а не Windows. Следовательно, если введены правила, с которыми могут быть введены ограничения, то документированы ли они?
GZ>В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:
GZ>1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:
GZ>

GZ>[Application]
GZ>ContextMenu = Show context menu

GZ>Ты можешь понять из текста, что это такое?
GZ>2. Существуют попутные технологии, которые могут описать семантику.
GZ>Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.
Re[18]: XML vs рукописный формат для конфигов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.09.05 16:29
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения?


Многие редакторы (в том числе и VS 7+) умеют на основании схемы делать подсказки или хотя бы на лету схему проверять, выдавая внятные сообщения об ошибках.
... << RSDN@Home 1.2.0 alpha rev. 610>>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.