Где вы храните большие списки свойств и настроек?
 

Всем привет, не нашел, поднималась ли уже данная тема, но вот я призадумался и стало интересно, кто как хранит множества разных параметров. Я сначала записывал настройки и свойства в хмл, откуда потом считывал, что мне нужно. Но хмл подводит, когда становится очень большой, некоторые свойства флеш просто не видит, словно бы их там и нет. Не знаю, может это особенность флеша такая, потому что при получении данных от сервера схожая фигня - когда данных много и поступают одни за другими сразу, строки ломаются или пропадают. Файлы .тхт вообще не рассматриваю - неудобно, имхо. Сейчас храню все большие списки свойств в виде статиков в классах - один хрен, да и обращаться просто.
А как делаете вы? Повторюсь. если эта тема уже поднималась, то дайте просто ссылочку.

Используй другой формат. Почему именно хмл? Самоубийца?

Никогда ничего из XML не пропадало...

Всегда в xml храню. Первый раз слышу, чтобы какие-то свойства были не видны.
Можно пример файла, в котором что-то не читается флешем?

ХМЛ конечно, но в последнее время json меня больше радует.

Ты даже настройки в json хранишь?
Я обычно его для обмена данными использую, но настройки в xml храню, ибо человекочитаемее )

Пока нет, но под джсон можно быстренько накалякать редактор. Просто я все больше пересаживаюсь на него. И если вдруг настройки должны будут приходить для юзера с сервера, то и переписывать немного. А хмл меня очень смущает своим нахождением в памяти. Иногда ощущение, что на каждый чих он создает кучу клонов ветвей и связок.

Какая то у вас XML фобия :)

У авторов редактора sublime тоже. Конфиги его, конечно меньше символов занимают, но строчек дофига :)

Да, XML - это крутой, мощный формат.
Удобен для текстовых данных (в CDATA завернул и не надо escape-последовательностей).
Поддерживающий xslt(которым можно проверить корректность данных, преобразовать XML в другой вид и т.д.)
Только Вы когда-нибудь пользовались xslt?
Нужно ли вам несколько вариантов трактовки набора узлов?

Если в JSON всё отлично ложится, человеку удобнее работать с JSON, то зачем использовать XML? Затем что он "более стандартный"?
Отрадно что Вы осознали всю мощь XML, но зачем она здесь нужна?
Сам использовал XML и для конфига и для справочных данных, но будь оно на JSON - нисколько бы не обломался (Тупо серверисту было удобнее на XML, а клиентщикам было всё равно)

Есть ещё YAML, но там отпугивют значащие пробелы в начале строки. И 2 способа записи одного и того же несколько сбивают кураж.
Хотя разработчиков Unity3d это не испугало - всё что можно при использовании текстового режима там хранится именно в YAML.

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

Передача запросов серверу делалась в amf3 всегда - компактно, руками их всё равно никто не пишет, бонус то что лишний раз хакеронубы не пытаются на лету поправить запрос(не нубам то это не преграда).

Возможно, в Вашей ситуации так и надо.
Но зачем же тогда делают внешние конфиги?

- чтобы поправить настройки при переносе флешки с сервера на сервер(чтобы не искать клиентщика с исходниками и не ждать пока он там всё настроит и перекомпилирует проект)

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

Скорее это особенность рук разработчика :) Тут либо что-то с сетью у Вас, либо чего-то не так в документации поняли.

у нас JSON, советую глянуть еще vanilla

Да, при переносе появляются некоторые заморочки с изменениями путей и перекомпиляцией, но это не проблема, по большому счету.
Возможно и так, мы с серверным программистом не нашли причину, почему так происходит( Пришлось ставить задержку при передаче в 0.3-0.4 сек чтобы не было разрывов строк.
Какой другой? Бинарный формат, вроде бы, один. Только в одном случае используется возврат каретки, а в другом нет.

Форматов много XML, JSON, AMF, ProtoBuf, ________(дописать свое)

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

caseyryan, пример файла не скину, его уже давно нет. Но там все стандартно: обращаюсь к хмл, все ветки читаю, но парочка-тройка просто не видны. Я создавал тут уже тему с этим вопросом и перепроверял все десятки раз, копипастами все имена забивал, чтоб точно без ошибок - один фик. Причем в 2х подряд проектах это наблюдал, пока не отказался от хмл.
С сервером схожая проблема: на сокет пришла строка, я распарсил и использую. Факт в том, что строка сразу уже может прийти оборванной, хотя в консоли сервера выводится нормально заканчивающаяся на EOF строка, которая отправлена во флеш. Такая фигня.

Фигня, в том что нечего обсуждать :)

Вообще XML и JSON считались всегда текстовыми форматами O_o
...если проблема в бинарных данных, то почему нельзя посмотреть что там за особые символы в текст попадают? Что с кодировкой?

AMF-3 - это стандартный формат сериализации flashplayer, бинарный. Может хранить массивы байт, текст, числа (кодируются негуманоиднее других типов), поддерживает циклические ссылки между сериализуемыми объектами и т.п.

Флешплеером читается/пишется нативно (Банальные методы ByteArray::writeObject и ByteArray::readObject используют AMF-3)
Для PHP есть библиотеки
новая спецификация - читать если решитесь править баги в PHP-либе, а так - не надо.

С AMF-3 можно сериализовывать/дисереализовывать _типизированные_ объекты при помощи registerClassAlias(), а можно не заморачиваться и использовать динамику (особенно если есть взаимодействие с PHP)

Т.е. если хотите попробовать AMF для конфига:

• Пишете редактор на AIR, который создаёт оъект динамический с нужными параметрами.
  Редактор сохраняет этот оббъект в ByteArray, сохраняет ByteArray в файл.
• Флешкой грузите этот файл как бинарный и читаете Object из ByteArray.

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