>> kan>Побило как ребёнка. >> Только при условии создания DOM-объекта kan>Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.
Нууу... Этааа...
Тут, правда, опять надо смотреть, что дешевле создать — объект или массив. Но это уже флуд на тему "а вот у нас в Forth под Берлином в сорок пятом..."
>>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти >>> > дорого. >> kan>Ну не создавай. Кто ж заставляет? >> Тогда не получится легкости типа payment = message.getRootElement() kan>Используй SAX.
Не хочу Я просто callback функции не люблю Но тоже вариант
>> kan>и сравни это с банальным SAX-фильтром. >> Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа >> response::key=value;; kan>Пусть так. Легче не станет.
>> Правда, оказалось, что я все же был неправ и тот gateway работает >> по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&only=1>
Здравствуйте, ZevS, Вы писали:
TBG>>Для дотошного пользователя, может быть. ZS>>>[/list] ZS>Извините, но это демагогия.
Да тут вся ветка демагогия, так что не обращайте внимания.
TBG>>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE. TBG>>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит. ZS>Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?
Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно ни к чему? Или вы со мной не согласитесь?
eao197 wrote: > Ну у меня в коде используется следующий подход: есть набор классов, > объекты которых хранят конфигурационную информацию. Именно эти объекты > используются в программе.
В Java я для этого использую XMLBeans. По XSD-схеме создается дерево
классов, которые можно загружать и сохранять в XML.
Причем этот XML можно обрабатывать хоть чем, подписывать его и т.п.
Turtle.BAZON.Group wrote:
> ZS>Правда? А если конфигурация — это не пара значений, а сложная > иерархическая структура? > > Если, если... Вот если, тогда и KEYPARENT.KEYCHILD=VALUE тоже сойдет. Но > это смотреть надо будет что проще. А вот для пары значений ХыМыЛ точно > ни к чему? Или вы со мной не согласитесь?
Может быть, в каких-нибудь ситуациях... Но обычно в итоге получается сложнее, чем <br />
XML
Здравствуйте, Mamut, Вы писали:
M>>> Экономить всегда полезно. GZ>>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
M>Ну, любой текст скукоживается
"Все люди равны, но некоторые равнее." (с)
Просто архивация как раз эффективно решеает проблему избыточности xml — много повторений, которые хорошо запакуются.
Таким образом если некие развернутые xml и csv соотносятся размером как 2/1, то в сжатом виде они будут уже гораздо-гораздо ближе друг к другу.
Здравствуйте, Mamut, Вы писали:
M>Ну и так далее вся секция integration такая
M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
M>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
ie>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х.
А что в Verisign и Yourpay испольщуется? Таки ХМЛ?
Здравствуйте, kan, Вы писали:
kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
[offtop]
А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше.
[/offtop]
kan>>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
A>[offtop] A>А не подскажешь пару-тройку таких вменяемых редакторов? Чем легче, тем лучше. A>[/offtop]
A>С Уважением, Andir!
Здравствуйте, Mamut, Вы писали:
M>XML Spy Suite один из, если не наиболее вменяемый
Тяжёлый он больно, как и впрочем Stylus XML Studio.
Мне бы что-нить лёгкое с посветкой и поддержкой XSD ака валидация, автодополнение, автогенерация. Остальные навороты практически не нужны (хотя от некого подобия рефакторинга не отказался бы).
Здравствуйте, Mamut, Вы писали:
M>>>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву. ie>>Довелось работать с 3мя платежками: Verisign, YourPay и Authorize.net. Так вот скажу, что Authorize.net как раз таки самая неудобная из этих 3-х. M>А что в Verisign и Yourpay испольщуется? Таки ХМЛ?
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>(я использую т.н. JSON+ формат)
A>Это в нём получается отказались от кавычек для имён полей? Дай ссылочку на описание, пожалуйста?
Это обычная нотация полного JavaScript.
Абсолютно ничего не мешает доточить парсер чтобы он принимал не только string здесь:
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Это затмение на людей нашло. Не развивается это дело больше никак.
A>Смотрел уже Javascript 1.7 ?
(Интересно а куда делась версия 1.6?)
С JavaScript вообще ситуация странная. JavaScript v.2.0 имплементриован только в .NET.
И похоже больше никто на его имплементацию за пять лет не сподобился. Неуловимый Джо?
А 1.7...
Ну в общем синтаксический сахар от Ruby (yield, generators/continuations) давно напрашивался.
Но все эти фичи и сейчас доступны в JS. (В любом языке имеющем closures можно исполнить continuation "руками".)
Поэтому в общем-то сильно оно не зажигает (лично меня во всяком случае). Будут востребованы эти фичи народом — сделаю их в tiscript.
Добавлять же в ту паукообразную обезьяну (SpiderMonkey) еще чего либо вообще смысла нет. И так не блещет скоростью то.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Мнение Алана Голуба: Just Say No to XML
К>Замечание несколько очень в сторону, но вот ещё одна альтернатива — CurlyML, очень похожая на JSON, но тоже лишь язык разметки
Тоже вот несколько в сторону:
Это вот фрагмент разметки и ЯП curl ( www.curl.com )