Why php5 DomDocuments need to be un/serialize()able
posted: March 2nd, 2005 · by: Sven
In our last post about “Template playing with php5’s Dom” we shared some thoughts about how to build a basic templating engine based on php5’s build-in dom extension. I have been playing around with that and have to say I found php5 dom’s lack of being un/serialize()able really annoying.
Why would anyone want to php un/serialize() a php Dom tree? A dom can be “serialized” to Xml, that’s human readable and non-proprietary! Creating a DomDocument and getting some Xml parsed is fast.
So, what the *%#~ is this about?
Ok, let’s take a minute to investigate that. Here’s an answer.
(Looks like there’s little understanding as to why we would need to do this even on the php xml dev’s list. You might want to have a look at this and, more arrogant, this statement.)
The new native dom exension is one of the really great news in php5 – no doubt. There are many really important usecases and no one would ever want to miss it again! We can easily read, manipulate, write xml elements and do more really nifty stuff with them. Cool :)
We can also extend the native php DomDocument class to add our own behaviour to it. We’ve shown just one example in “Template playing with php’s Dom”. So let’s take that example.
Here we use the DomDocument class to parse an html (xml) template and build up a controller tree, that’s aligning necessary behaviour (unfortunately, the php dom extension doesn’t provide any hooks, e.g. to add our behavior to DomElements). Than we let the controller tree react on some user input (request parameters, ...) and manipulate the DomDocument’s elements and data. Afterwards we let DomDocument output the html.
That’s great. And in our days of 1001 different php template engines that usually don’t care about standard-compliance at all: it could probably be a way to bring the php community some inches nearer to recognize and use standards.
But of course: we can’t do it this way. Using a template with some more than 50 tags gets terribly slow. With each request php starts up the whole environment from a dark void of nothingness and therefore most of php’s greatest template engines like Wact or Smarty use some “template-compile” stage and cache the results to files to recreate them later on.
Ok, there are some php templating engines/frameworks out there that go a comparable way – besides from that they don’t use php5’s native dom support but some own, homegrown stuff to parse their templates. Prado is possibly one of the best known of them.
Prado builds up each component from its templates and component-definition xml files and caches them. After having done that once, these ready-made components will get fetched from the cache and used. The parsing of the templates and their translation to php objects will be by-passed this way and performance gets considerably faster.
In our experiment striving for a templating engine that uses php5’s native dom extension as described here, we’ve tried to get around that limitation that dom objects simply can’t be un/serialized with php’s native un/serialize() functions. But there’s no simple way around it.
We can save some milliseconds by recovering data that have already been set to our controller tree. But we’ll always have to ...
- lookup and read the template (that’s fast, depending on our system)
- re-create the DomDocument from the template (ok, that’s even very fast) and
- re-create the references pointing from our controllers to the appropriate DomElement (that’s worse, depending on the complexity of the template and the needs of our controller).
This is a basic problem. It’s a serious limitation of possible usecases of the php5’s dom extension. We won’t ever be able to attach our own behaviour to DomDocument/Element objects unless we are willing to:
- re-create the references to the DomDocument/Element instances at every request or
- throw away the idea of having complete components cached in a ready-made state that can be used to set up the application in a (comparatively) very short time.
Conclusion: php5 DomDocuments need to be un/serialize()able.
Let’s advocate for it.
Cameron said June 11th, 2005 at 11:28 AM ¶
Why not just re-create the DOM in PHP5 code?
Seems like the easiest solution to me. The specs over at the W3C provide very detailed interfaces for all that's needed and PHP5 is definatly up to the task:
W3C Document Object Model Core
Couple this with the XML parser functions (also quite fast) to parse the templates into the DOM and you have a complete solution.
After playing with PRADO for a while I liked it's implimentation but wanted something a little different and ultimatly decided to do what you're wanting. Alas, it's for a close source project I can't name at the moment, but it's working quite well thus far and the DOM only took a few days to code in PHP5 working form the W3C spec I linked to above.
Sven said June 11th, 2005 at 10:42 PM ¶
Cameron,
so you've implemented DOM in php5 userland?
Well, yes. Of course that could be a possible solution. And I am interested in further details here of course :) You might want to have a look at my article A Php userland Dom Contest concerning that.
But I don't think that any userland implementation can reach the speed of the native DOM support in php5. So that's why the conclusion of this article still is true in my eyes: php5 lacks serialization of DOM instances.
jack said January 24th, 2011 at 03:29 PM ¶
UCVHOST has changed the face of web hosting industry in a major way, people were paying gold for peanuts (and it is still happening). cheap hosting has become synonym with UCVHOST, anybody and everybody who wants a reliable and affordable domain web hosting visits UCVHOST and gets either windows vps or Linux hosting from UCVHOST. UCVHOST sells cheap hosting WITHOUT hidden terms and conditions where as competition has huge MSA and SLA’s which are good enough to confuse a seasoned lawyer also. For clients by now Business with us for the value of windows vps became very critical piece of puzzle for their whole operation, uptime and performance became a huge concern.. However it came with a cost, dedicated servers proved to be at least 100 times expensive in comparison to any windows or Linux plans. Somewhere in the labs engineers were working on splicing raw power of a server into virtual instances, this technology was called as Virtualization also termed as or virtual private servers. Also UCVHOST comes handy when you are looking for remotely hosted and managed FOREX MetaTrader4 terminals. Our forex vps platform is all geared up in fight of pips, our platform support any number of expert advisory (EA) and along with an assure of 100% uptime. Our Virtual Forex Tradng Terminals are well equipped to help you in making money .
chat said March 31st, 2011 at 08:24 PM ¶
The following cleaned up the issue:
Dependencies.loadoncepaths -= Dependencies.loadoncepaths.select{|path| \ path =~ %r(^#{File.dirname(FILE)}) }
Okey oyunu said May 12th, 2011 at 04:31 PM ¶
Thanks a lot. This is nice post. Tüm dünya artik okey oyunu oynuyor. Yillardir bir çok oyun programi olmasina ragmen, içlerinden en güzeli olarak nitelendirebilecegimiz tek bir site göze çarpmaktadir. Diger tüm okey oyunu programlarinin aksine ücretsiz olmasi ve 3 boyutlu olarak hizmet vermesi mükemmel bir gelismedir. Sizlerde www.okey-oyunu.com adresinden bu essiz okey oyununu indirebilirsiniz. Kullanimi çok basit ve Türkçe dil seçenegi ile kolaylikla oyuna baslayabilirsiniz. Ister kendi ülkenizden, isterseniz dünyanin tüm farkli bölgelerinden dilediginiz oyun odalarini seçerek, oyuna hemen baslayabilirsiniz. Okey oyunu oynamak için artik arkadas bile aramaniza gerek kalmadan, bilgisayarinizdan 100 binlerce üye ile online olarak okey oyununu oynamanin zevkine varabilirsiniz.
Daniel said May 13th, 2011 at 10:09 PM ¶
Nicht schlecht, schön zu sehen, dass die Seite schon seit so vielen Jahren existiert und nützliche Tipps gibt. Ich suche grad für mein fernseher test Seite einige nützliche Informationen zu den alten PHP5 versionen. Danke für die Tipps.