Symphony.

I recently made some experiments to get XMLElement work with DOMDocument. As you know, Symphony3 replaces our beloved XMLElement with the outperforming combo XMLDocument + SymphonyDOMElement.

But, if you feel brave, you can test a similar solution in Symphony2. It doesn’t work flawlessy yet… in fact it works only in Frontend and there are problems with dynamic datasources (and probably many other problems I’m not aware of).

I’ve packaged the result of my experiments as an extension. There are a few steps to follow in order to make it work, so be sure to backup your files before entering hack-mode.

Follow these steps to install.

The extension provides a new class: DomDocXMLElement. This class is loaded by default (only in Frontend, remember) in place of the original XMLElement class. If you want to switch back to XMLElement at runtime, just append ?use-legacy-xmlelement to the url.

I also included some stats at the end of html source (almost the same you find in ?profile).

Conclusions

You won’t notice any boost with small datasets, indeed, XMLElement may slightly perform better in some situation. But with large datasets you will see improvements in the xml generation time and dramatic improvements in terms of memory.

With a single datasource pulling from a section with something like 3.5k entries, memory consumption decreased from ~140mb to ~5mb.

It certainly breaks other things and should only be taken as an experiment. Have fun! :)

Attachments:

domdoc_xmlelement.zip

Wow, Marco. Is this how you spend your free time? ;-)

Does this imply that you are able to use the old XMLElement syntax but that DomDocument will be used internally? If yes: is this something that’s in the scope of 2.2?

Great experiment! I’ve found a possibly fundamental blocker for this implementation: if you’ve been using the XMLElement in custom code, then you’ll be used to using getChildren() and having more XMLElement objects returned. This version will return a DOMNodeList, which if you iterate over you get a series of DOMElement objects, which means you can’t then call existing XMLElement methods on (such as getName() for example).

The only solution I can think of is to subclass the native DOMElement and add these methods, but that sounds potentially messy.

I’m working on commenting out my custom Data Sources to see how this works with native code only…

Does this imply that you are able to use the old XMLElement syntax but that DomDocument will be used internally?

Yes. It works only in Frontend because DomDocument requires a well-formed XML document. We can safely assume this requirement is satisfied in the current Frontend implementation because, in the end, what’s generated with XMLElement is parsed and loaded into a DomDocument instance.

The same doesn’t apply for Backend, but it’s coherent. There is no XSLT processor behind, so no well-formed document is expected. The backend should provide the full power and freedom that a developer needs to build extensions and fields: you can’t make any assumption about the document that will be generated. Therefore I think keeping the current XMLElement implementation is fine.

is this something that’s in the scope of 2.2

I don’t know, but I believe we can get pretty far with this.

if you’ve been using the XMLElement in custom code, then you’ll be used to using getChildren() and having more XMLElement objects returned

Yeah, that’s true… maybe we could just loop over the nodelist and return an array of XMLElement instances instead?

Is this how you spend your free time? ;-)

lol

Yeah, that’s true… maybe we could just loop over the nodelist and return an array of XMLElement instances instead?

True. But doesn’t mixing the two defeat the purpose?

is this something that’s in the scope of 2.2

I’d love to say yes, but I think this might be a change too far given the timescale for 2.2. The next release is about stability and I’d be concerned that such a fundamental change could break compatibility with all sorts of code that has previously used the XMLElement API.

Still, it’s great to see this moving forward.

(Sheesh, S2 becomes more and more like S3 every day… ;-) )

True. But doesn’t mixing the two defeat the purpose?

Sorry, I meant DomDocXMLElement. Class aliasing arises some ambiguities in terminology :)

I agree about having this out of the core.