Write to XML

[RWB]

I can't seem to get any kind of answer on this... how do you write information to an XML file? Say you fill out a form, and that form sends information to an XML file so I can view it in a web page, kinda like a forum, but on a smaller scale.

[Lincoln]

XML is just text, so you'd write it like any other file with whatever scripting language you're using, just give it a .xml extension.

PHP's file_put_contents (http://us2.php.net/manual/en/function.file-put-contents.php), for example.

[RWB]

Thanks, I'll look into that, any other tips perhaps?

[Lincoln]

Not unless you tell me what it is you're trying to do - that was the best I could do since your goal was pretty vague. XML is quite simple, the only rule is to close every tag you open, and in the correct order. :)

[RWB]

Ohh yeah XML is easy as pie, but it's the other stuff that makes it complicated... I made this yesterday when our ticketing system went down...



<?xml version="1.0" encoding="ISO-8859-1"?>
<tickets>
<newTicket>
<ticketNum>028</ticketNum>
<status></status>
<hotelBrand></hotelBrand>
<hotelLoc></hotelLoc>
<roomNum></roomNum>
<problemType></problemType>

<callDetails>
<timeStamp>12:07PM</timeStamp>
<callNotes></callNotes>
</callDetails>
</newTicket>
</tickets>



<tickets>Of course, it doesn't do anything... it's justthat instead of putting random notes into a .txt file like such...

Room 416 @ Hotel B
Getting LONC, checked connections, bypassed nose, still LONC, set S&D to 10Full, connected, gtg.I made it more... crazy... hehe. Started thinking of how I would build my own ticketing system for ****s and giggles is all... maybe even to replace the crappy one we have that's always breaking and is slow as all hell.</tickets>

[RWB]

BTW when I edit my post to fix the code... it appears to break the code... in edit mode it doesn't show up, the PHP tags show up, but the actual tags and such don't show.

[Lincoln]

I guess that makes sense, but are you sure you need XML for that? It seems to me a database would be better suited to a ticketing system. XML is generally used for two systems to communicate, not for storing info for a single system (though it can be...).

[RWB]

****s and giggles my friend.... ;)

[BLuKnight]

I agree that a database would be best for a ticketing system. You need to spend extra time ensuring that two processes don't write to the same file at the same time.

However, XML can be used for more than just communication. Reading from files is way faster and less costly then making a database connection. I enjoy using XML for static information that can be changed in a central area, like a menu. I also find it useful for localization. (I hope I used the correct CS term... Great topics but I really disliked the professor.) I can create a translation for a website and as I add a language, just update the XML.

XML rocks!

[RWB]

That's a given but I can't really think of anything cool to work with on XML and I wanna play.

[lightnin]

what language? you can compile some xml processing tools into php, and java 1.5 has lots of nifty stuff built in to the native j2se sdk. i'm looking into jaxb right now but it's fairly complex...

you could store your data in a db, then pull it out as xml and use xslt to display it in a web app. that happens a lot in portal environments, and is a pretty nifty MVC model....

[RWB]

Is it faster to store information in SQL, retrieve to XML and post the information? What is the fastest method for storing large amounts of data?

We're talking PHP, MySQL, and XML... I definitly wanna be able to port information to XML at the least. But how large of information can XML hold in a single file?

[BLuKnight]

Reading from a flat file, like XML, is always faster and less expensive (process wise) than an SQL query. However, when you start writing, you get into issues that SQL does a better job at. For instance, SQL does a better job at preventing (if done properly) people from writing at the same time. You can do that with XML, but it's more inefficient. Plus as the file grows, your ability to maintain it is reduced.

My suggestion... anything Static that you want to easily change, place it in XML. (Like a price list... unless you're newegg) If you're going to be reading and writing, SQL is the way to go.

[lightnin]

I'm with BluKnight on that one. it's hard to beat even a crappy rdbm by writing anything to flat files with any regularity. you do get into resource locking eventually. that being said, nothing says you can't do it, like you said, for the heck of it.

for php :
writing xml is pretty easy, check out
http://us.php.net/manual/en/ref.xmlwriter.php

http://us3.php.net/manual/en/ref.xml.php
full xml reference

for java :

http://java.sun.com/webservices/jaxp/dist/1.1/docs/tutorial/dom/4_create.html
this one specifically creates an xml file

http://java.sun.com/xml/tutorial_intro.html
this is the xml tutorial intro

edited to ramble on a bit:


But how large of information can XML hold in a single file?


that depends on your OS more than anything... and how fast you need to process things... ;)

it's possible to process xml pretty quickly, of course depending on the structure of the file and the algorithm you use to marshal/unmarshal the data within the file.

the RDBM will help you in *searching* for data and retrieving data based on specified criteria. that would be a pill across multiple xml files unless of course you only ever search on ONE key, like date or ticket number... in that case you could simply name each file using that key and open that file locally using that unique identifier.

if you ever got into higher volumes of traffic on the system, performance would degrade faster this way than using a RDBM esp if you write to those files often. reading wouldnt be so bad IMHO... if your xml processing code wasn't chock full of recursion...

i tend to like the idea of xslt web apps. you could open each file and directly transform the data within the file to html for display without having any transfer/value objects. which is pretty cool actually, in theory it would cut down on the amount of code you have to write... except for those pesky xslt stylesheets. my only beef with them is that it's usually a real PITA to design/debug stuff without a nifty ide.

[lightnin]

since this thread started i've integrated JAXB into my current project where i'm pulling xml from a service and mapping it to a set of db tables to normalize the data a bit for use in several other apps.

i have to say, compared to two other methods of parsing/marshaling the xml into data objects (xpath and 'treewalking') JAXB is ridiculously faster at marshaling data from xml into java objects.

on top of that, you create a context to look up the url of the xml feed, and you can cache that context for a little more efficiency.

it's a good deal all the way around.