Xpoint
   [напомнить пароль]

Обмен XML между браузером и PHP

Метки: [без меток]
2011-04-08 08:02:37 [обр] Artem[досье]
Помогите с информацией (лучше на русском) по данному вопросу.
Начитавшись деклараций о бешеном преимуществе XML захотелось построить обмен между браузером и сервером именно в этом формате. В теории выглядит всё прекрасно: у клиента приложение на JS, он щелкает на кнопочки, провоцируя запросы и отправку с/на сервер XML файла, трафик падает, серверная часть сильно упрощаеться, так как не надо формировать представление документа, и т.д., и т.п.
Не тут-то было: в интернете куча примеров как сделать какой-нибудь красивый функционал с помощью обработки XML, но все примеры довольно примитивны и обработка представления осуществляется с помощью того же JavaScript-а. А как быть если данные надо вывести не в виде списка, а создать довольно сложную форму? А если инструмент не один? Вроде такую проблему можно решить подключая XSLT, но как вытянуть с сервера XML с уже подключенным XSLT, JavaScript его ингорирует напрочь.
И самое главное: не могу найти информации как на PHP обрабатывать полученный от браузера кусок XML. Вроде бы нашёл интересную статью: http://www.interface.ru/home.asp?artId=9043, но тут только отправка XML - и всё. А дальше-то что? Сервер должен принять эти данные, и как-то они должны обратно вернуться.
В общем, интересует какая-нибудь серъёзная информация по этому поводу с хорошей теорией и примерами.
Спасибо за внимание.
спустя 6 минут [обр] Евгений Седов aka KPbIC(0/176)[досье]
М Перенесено из форума "Программирование::PHP"
спустя 1 час 18 минут [обр] Павел Карасёв(0/14)[досье]
спустя 3 часа 38 минут [обр] Thirteensmay(0/157)[досье]

Тут первичен вопрос архитектуры а не XML. Т.е. то соображение что вместо отдельных подгружаемых страниц в браузере постоянно висит JS приложение. По сравнению с перезагрузкой страниц есть плюсы и минусы, выбор зависит от специфики проекта, если у вас классический Web-ресурс, новостной сайт, блог, форум и т.п, то лучше перезагрузка, возможно с XSLT и элементами AJAX, а если именно приложение, как традиционное локальное, с высокой динамикой, богатыми контролами, то лучше второе.

Конечно некоторое снижение объема передаваемой информации, в общем, имеет место быть, но это сильно вторично, как следствие увеличивается количество мелких запросов. Первичным же является удобство и богатство интерфейса, организуемое за счет соответствующих библиотек типа ExtJS, XSLT тут как правило не используется, рендерингом представления занимается сама библиотека, вместо XML как более экономный используется JSON, хотя можно и XML.

Переход с перезагрузки страниц к JS приложению, без улучшения представления, особо ничего не дает, значительное же улучшение представления на основе голого JS и XSLT, без использования библиотек типа представленной выше, их богатых контролов и подходов, дело достаточно хлопотное и неблагодарное. Также надо учитывать, что богатое JS приложение повышает требования к клиенту, не столько в области поддержки и совместимости, с этим все более-менее нормально, сколько по производительности. На слабых клиентских машинках, по сравнению с вариантом перезагрузки, интерфейс начинает тупо тормозить.

Еще один момент - объем первоначально загружаемых данных, JS приложение с учетом библиотек получается относительно большим, конечно его можно подгружать по мере необходимости, но это не всегда возможно. В результате на узких каналах время первоначальной загрузки и инициализации может быть весьма существенным. Впрочем, проблемы с производительностью клиентов и каналов со временем по очевидным причинам ослабляются.

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

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

спустя 2 часа 45 минут [обр] Marat Tanalin(0/78)[досье]
Есть смутное подозрение (могу ошибаться), что надо начать с основ.
спустя 3 часа 14 минут [обр] Artem[досье]
[[xpointUser7240 MT], Ну может я несколько коряво спросил. Понятно что PHP ничего на странице отобразить не может. Мне сам механизм не совсем понятен: вот, например, как на приведённой мною ссылке, объясняется принцип формирования запроса по xmlHttp... и дальше идёт рассказ как туда методом get или post передать ПЕРЕМЕННЫЕ! Спрашивается, при чём здесь xml? Как обрабатывать на сервере переменные тоже понятно, а переданный xml? Он как приходит в виде отдельной переменной? Вот этой информации и не могу найти, думал может есть уже какие-то встроенные методы (у Javascript-по формированию и передаче, у PHP-по обработке) в xml формате.
Thirteensmay[досье], спасибо, внимательно изучу.
спустя 18 минут [обр] Jared(0/26)[досье]
Artem[досье], вам что не понятно конкретно? Как в PHP работать с XML?
http://ru2.php.net/manual/en/class.domdocument.php
спустя 56 минут [обр] Marat Tanalin(0/78)[досье]
Artem[досье]
На сервер XML обычно передавать незачем. XML обычно получают с сервера с помощью Ajax-запроса. В настоящее время, впрочем, вместо XML обычно используется JSON. В PHP для генерации JSON-строк есть встроенная функция json_encode.
спустя 46 минут [обр] Thirteensmay(0/157)[досье]
На сервер данные как правило уходят не в XML, а как обычно полями форм при их отправке, и параметрами запросов, и обрабатываются на сервере в скрипте классическим образом. А вот с сервера, да, можно получать в XML или JSON (более экономично). При этом библиотеки как правило избавляют от необходимости распарсивать полученные данные и вручную грузить их в контролы интерфейса, необходимо лишь передавать в соответствующем контролу формате. Например загрузка грида в ExtJS осуществляется элементарно Grid.Store.load(URL); Где по указанному URL располагается скрипт отдающий данные, причем в настройках Grid.Store можно указать формат получаемых данных.
спустя 20 часов [обр] Artem[досье]

Jared[досье]
Ну вот кусок на js (с той же страницы), например:

var url = "/scripts/saveAddress.php";
xmlHttp.open("POST", url, true);
xmlHttp.setRequestHeader("Content-Type", "text/xml");
xmlHttp.onreadystatechange = confirmUpdate;
xmlHttp.send(xmlString);

Для чего он? Отправить XML на сервер, как его там подхватить? Что надо добавить к этому скрипту чтоб выдернуть результат обработки? В чём преимущество перед передачей простых данных?

спустя 2 часа 13 минут [обр] Thirteensmay(0/157)[досье]
Ну, на PHP не пишу, но на вскидку входные данные смотрите в $HTTP_RAW_POST_DATA, для их распарсивания и работы с XML есть несколько вариантов: SimpleXML, XMLReader, DOMDocument. Результат обработки в вашем JS скрипте грубо говоря будет в функции confirmUpdate, тут почитайте про AJAX и XMLHTTPRequest, как им пользоваться. С XML также особо дружбы не вожу, но если я все правильно понимаю то в JS для работы с XML можно использовать DOM функции (если у вас XHTML), получать XML содержимое узла можно через свойство innerHTML.
спустя 41 минуту [обр] Thirteensmay(0/157)[досье]
Только я таки не понимаю, зачем вам весь этот геморой, если у вас обычный web-ресурс как я писал выше, то и не к чему оно, по моему, лучше применять классический подход, возможно с использованием XMLHTTPRequest конечно, но и тут проще перекидываться обычными текстовыми кусками данных, параметрами, формами. Если же у вас Приложение, то библиотеки типа ExtJS сделают за вас всю эту грязную работу автоматически. Все это AJAX хозяйство предназначено для закладки фундамента, обеспечения возможности разработки больших и сложных web-приложений, это их низкоуровневая основа, как ассемблер, геморойная, на фоне наличия удобных высокоуровневых библиотек. Свою ExtJS вы не напишите, тогда смысл ?
спустя 1 час 35 минут [обр] Jared(0/26)[досье]

Artem[досье] Этот кусок кода постом отправляет xmlString на сервер, дополнительно указав тому, что данные это - text/xml. PHP не будет распарсивать такой POST, он хочет Content-type: application/x-www-form-urlencoded либо в заголовках запроса, либо в его теле. Таким образом вам нужен $HTTP_RAW_POST_DATA, как и сказал Thirteensmay[досье]. Далее на сервере:

<?
$doc = new DOMDocument();
$doc->loadXML($HTTP_RAW_POST_DATA);
#Ваш DOM готов, делайте с ним что хотите
?>

Этот код - копипаста из документации, приведенной по ссылке.

спустя 32 минуты [обр] Jared(0/26)[досье]
В чём преимущество перед передачей простых данных?

Что вы имеете в виду под "простыми данными"?
Кроме XML формата можно отправлять данные в любом другом, если он подходит под требования к структуре данных. Можете хоть в каком-нибудь бинарном формате отсылать, если это оптимально для решения задачи.
Сейчас широко используюся кроме XML два варианта - аналог хеш-массивов (key->value массив, классика и дефолт) и JSON.
Дефолтный вариант самый простой, но и накладывает ограничения на структуру данных. Скажем, иерархическую структуру сформировать без извращений и костылей нельзя.
JSON куда как сложнее, позволяет создавать те самые иерархические структуры.
XML - еще сложнее.

Для 98% задач key->value или в JSON формат достаточен. В оставшихся 2% использование XML может быть связано не только с большей сложностью и возможностями формата, но и с особенностью инфраструктуры проекта.

спустя 8 дней [обр] Artem[досье]
Спасибо всем ответившим, хотелось бы ещё поговорить на эту тему, но, к сожалению, пока нет времени.
Powered by POEM™ Engine Copyright © 2002-2005