470,848 Members | 1,111 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,848 developers. It's quick & easy.

xml parsing with php


I use PHP (and PHP socket functions) to exchange very short XML
documents between two Flash clients like this :
<MESSAGE id="myid" text="mytext" />
I don't parse the XML document within PHP but send back the XML document
made by the Flash client to another Flash client with a php socket and
Flash parse it with its own XML parser ...
In order to detect errors or non-XML data I do like this (in php):

switch (true){
case ( ereg("\<", trim($XMLdata)) ):
print 'xmldata';
print 'no xmldata';

(I must do this because Flash sends an empty "heartbeat" every 5
seconds, which is not XML data)
Now, I need to interpret my XML document inside php cause I want to make
php execute some commands when it receives a certain type of XML element.

XML data that can be sent from Flash :

<MESSAGE id="myid" text="mytext" /> or
<COMMAND1 /> or
<COMMAND2 /> or
or an empty string "" .

(in php) I can do :

switch (true){
case ( ereg("\<MESSAGE", trim($XMLdata)) ):
print 'xmldata is a txt message';
case ( ereg("\<COMMAND1", trim($XMLdata)) ):
print 'xmldata is a command1';
case ( ereg("\<COMMAND2", trim($XMLdata)) ):
print 'xmldata is a command2';
print 'no xmldata';

But what I'm wondering is whether it is the good way to proceed,
wouldn't it be faster to parse the xml document within php with Expat
library included when it receives a document "<COMMAND idcom="1" />" and
interpret "idcom" value instead of doing an "ereg("\<COMMAND1",
trim($XMLdata)) ?
many thanks,

Jul 17 '05 #1
0 1926

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Gerrit Holl | last post: by
16 posts views Thread by Terry | last post: by
9 posts views Thread by ankitdesai | last post: by
5 posts views Thread by randy | last post: by
13 posts views Thread by Chris Carlen | last post: by
7 posts views Thread by Daniel Fetchinson | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.