Serialization of XML

[wbond]

Ticket #492 by @mattsah:

Are there any plans to add serialization of XML to fXML? It would be kinda cool if I could use fJSONencode and fXMLencode similarly. I understand there are conceptual differences between what these do, but it seems like fXMLencode is simple enough that it could just check if it was receiving a string and do it's normal string encoding… but if it were an object, perhaps it could iterate over the object creating elements for each of it's attributes or if it were an array of objects, multiple elements, returning a string of XML that could then be placed inside a root element.

It may also be cool to add support for pseudo toXML or toJSON methods for non-stdClass objects which could return custom stdClass objects with private properties etc.

Comment by @wbond:

There are a few issues I see with this:

• What would the root element be for an array or object? and ?
• What would the element be for items in an array? ?
• Further, if an array while an element in an object, would the array element be the name of the object property or the same thing as a root-level array?

I found a jQuery plugin that does something similar to what you are looking for: http://michalkorecki.com/content/introducing-json-xml-jquery-plugin. I see the example falling down if "students" was an array instead of a object with a single property called "student" that was an array. The later seems like it would be a more common data structure.

I wouldn't be opposed to adding such a thing if we can come up with a solid and intuitive set of rules for converting a JSON data structure to XML (just because we already know the PHP → JSON mapping rules).

Comment by @mattsah:

Some of what you raise is things that I was contemplating, and to me it all revolves around the question of why/when someone might be wanting to serialize something to XML. It seems to me both the API and recursion might benefit from an optional second parameter for use when encoding objects that would result in the string passed being used as the root element, so for example if I did the following:

$users = array(
    array(
        'name' => 'Matthew J. Sahagian',
        'dob'  => 'April 28th, 1984'
    ),
    ...

);

fXMLencode($users, 'users');

I might get something back such that:

<users>
    <item index="0">
        <name>Matthew J. Sahagian</name>
        <dob>April 28th, 1984</dob>
    </item>
    <item index="1">
    ...
    </item>
</user>

If the parameter is left null, arrays could use simply "data" while objects could perhaps default to the underscorized class name, or only in the event of stdclass… data.

Where keys/property names are used the element would obviously reflect these as in the above example.

I think data / item are good defaults for roots + numerically index array elements.

Obviously if someone creates an insanely nested array with no keys and then complains about all the recursive "data" elements, it is their own fault.

In the event of a numeric key pointing to an array you might get something like:

<data>
    <item index="0">
        <data>
            ...
        </data>
    </item>
</data>

As I mentioned when I opened, I feel the big question is going to be a matter of how it tends to be used by people… I think it's fairly rare that someone will be serializing non-associative arrays. And objects have the very useful distinction of having their property names to identify things. Perhaps this is at least a start to the concept? Obviously, the onus to create the desired format will be on the user giving keys/properties as appropriate to their arrays. As mentioned with a conception for _toJSON and _toXML (how do you escape tow underscores in this thing?) I feel this will likely get used the most in models, whereby the class name will be a good indicator as to what to call an element.

$users = Users::build(array('username~' => 'matt'));
fXML::encode($users->getRecords(), 'record_set');

<record_set>
    <user>
        <first_name>Matthew</first_name>
        <last_name>Sahagian</last_name>
        ...
    </user>
    ...
</record_set>

Comment by @wbond:

After talking with some different developers, here is the idea I have:

1. The parameters for fXML::encode() would be: $value, $root_element_name='root', $array_item_element_name='item'
2. $array_item_element_name could accept either a string, or an associative array of parent_element_name ⇒ array_item_elemenet_name for making custom tags in arrays
3. Any array elements that have a key that is not a valid element name would become an item tag with an attribute name="{key}"
4. Any array keys that start with @ would become attributes of the parent tag
5. fXML::encode() would continue to accept scalar values, and would only use the new parameters for arrays or objects

Does this sound like a solution that would work for you?

Comment by @mattsah:

This seems quite alright and as far as I can tell quite in line with what I originally had in mind. It seems in most cases that common XML subformats or microformats are fairly simple and I would imagine most people will be using them with appropriately structured objects or associative arrays, but it will be good to have the option to override both.

With regards to scalar values, indeed!

Comment by @wbond:

When I was at PHP|Tek 11, one of the guys from Frapi did a presentation and talked about how they support both XML and JSON. There was some discussion about how they translated arrays into XML. Since they have some traction in the PHP API arena, I think it would be good to emulate them as long as it isn't too crazy.