Просмотр полной версии : Где вы храните большие списки свойств и настроек?
Всем привет, не нашел, поднималась ли уже данная тема, но вот я призадумался и стало интересно, кто как хранит множества разных параметров. Я сначала записывал настройки и свойства в хмл, откуда потом считывал, что мне нужно. Но хмл подводит, когда становится очень большой, некоторые свойства флеш просто не видит, словно бы их там и нет. Не знаю, может это особенность флеша такая, потому что при получении данных от сервера схожая фигня - когда данных много и поступают одни за другими сразу, строки ломаются или пропадают. Файлы .тхт вообще не рассматриваю - неудобно, имхо. Сейчас храню все большие списки свойств в виде статиков в классах - один хрен, да и обращаться просто.
А как делаете вы? Повторюсь. если эта тема уже поднималась, то дайте просто ссылочку.
MikroAcse
29.05.2013, 20:01
Используй другой формат. Почему именно хмл? Самоубийца?
Никогда ничего из XML не пропадало...
caseyryan
29.05.2013, 21:29
Всегда в xml храню. Первый раз слышу, чтобы какие-то свойства были не видны.
Можно пример файла, в котором что-то не читается флешем?
ХМЛ конечно, но в последнее время json меня больше радует.
caseyryan
29.05.2013, 21:43
Ты даже настройки в json хранишь?
Я обычно его для обмена данными использую, но настройки в xml храню, ибо человекочитаемее )
Пока нет, но под джсон можно быстренько накалякать редактор. Просто я все больше пересаживаюсь на него. И если вдруг настройки должны будут приходить для юзера с сервера, то и переписывать немного. А хмл меня очень смущает своим нахождением в памяти. Иногда ощущение, что на каждый чих он создает кучу клонов ветвей и связок.
Какая то у вас 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 (https://github.com/jonnyreeves/as3-vanilla)
Возможно, в Вашей ситуации так и надо.
Но зачем же тогда делают внешние конфиги?
- чтобы поправить настройки при переносе флешки с сервера на сервер(чтобы не искать клиентщика с исходниками и не ждать пока он там всё настроит и перекомпилирует проект)
- чтобы компилировать одну и ту же флешку и на тестовый сервер и на боевой (а на этих серверах лежат разные конфиги)
Это реально старовится проблемой при частых обновлениях и большом количестве целей - можно ошибиться не ту версию скомпилировать/залить, не те параметры поставить - работать перестанет, а так - везде заливаешь одно и то же и голову себе не забиваешь.
(можно даже при достаточном уровне настраиваемости заливать одну и ту же флешку и на мой мир и на одноклассники и на вконтакт, к примеру)
Да, при переносе появляются некоторые заморочки с изменениями путей и перекомпиляцией, но это не проблема, по большому счету.
Скорее это особенность рук разработчика :) Тут либо что-то с сетью у Вас, либо чего-то не так в документации поняли.
Возможно и так, мы с серверным программистом не нашли причину, почему так происходит( Пришлось ставить задержку при передаче в 0.3-0.4 сек чтобы не было разрывов строк.
Используй другой формат.
Какой другой? Бинарный формат, вроде бы, один. Только в одном случае используется возврат каретки, а в другом нет.
Форматов много XML, JSON, AMF, ProtoBuf, ________(дописать свое)
Форматов много XML, JSON, AMF, ProtoBuf, ________(дописать свое)
По-факту, это все те же бинарники, часть данных из которых куда-то отваливается. Вот AMF мне интересен, есть где-то пример работы с ним?
caseyryan, пример файла не скину, его уже давно нет. Но там все стандартно: обращаюсь к хмл, все ветки читаю, но парочка-тройка просто не видны. Я создавал тут уже тему с этим вопросом и перепроверял все десятки раз, копипастами все имена забивал, чтоб точно без ошибок - один фик. Причем в 2х подряд проектах это наблюдал, пока не отказался от хмл.
С сервером схожая проблема: на сокет пришла строка, я распарсил и использую. Факт в том, что строка сразу уже может прийти оборванной, хотя в консоли сервера выводится нормально заканчивающаяся на EOF строка, которая отправлена во флеш. Такая фигня.
Фигня, в том что нечего обсуждать :)
По-факту, это все те же бинарники, часть данных из которых куда-то отваливается. Вот AMF мне интересен, есть где-то пример работы с ним?
Вообще XML и JSON считались всегда текстовыми форматами O_o
...если проблема в бинарных данных, то почему нельзя посмотреть что там за особые символы в текст попадают? Что с кодировкой?
AMF-3 - это стандартный формат сериализации flashplayer, бинарный. Может хранить массивы байт, текст, числа (кодируются негуманоиднее других типов), поддерживает циклические ссылки между сериализуемыми объектами и т.п.
Флешплеером читается/пишется нативно (Банальные методы ByteArray::writeObject и ByteArray::readObject используют (http://help.adobe.com/ru_RU/FlashPlatform/reference/actionscript/3/flash/utils/ByteArray.html) AMF-3)
Для PHP есть библиотеки (https://www.google.ru/search?q=php+amf3&oq=php+amf3)
новая спецификация (http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/amf/pdf/amf-file-format-spec.pdf) - читать если решитесь править баги в PHP-либе, а так - не надо.
С AMF-3 можно сериализовывать/дисереализовывать _типизированные_ объекты при помощи registerClassAlias(), а можно не заморачиваться и использовать динамику (особенно если есть взаимодействие с PHP)
Т.е. если хотите попробовать AMF для конфига:
Пишете редактор на AIR, который создаёт оъект динамический с нужными параметрами.
Редактор сохраняет этот оббъект в ByteArray, сохраняет ByteArray в файл.
Флешкой грузите этот файл как бинарный и читаете Object из ByteArray.
Для набора простых параметров делать редактор - дико, но можете попробовать.
Для начала не стоит делать функции редактирования - просто кодом создайте объект - посмотрите, его то хоть удастся загрузить.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.