The same way I showed in the previous example. You can nest the cmd:forXXX any way you like. You just have to know which keys/indexes point to arrayrefs, which to hashrefs and which to scalars. And use the cmd:forkey, cmd:forkeys or filter the cmd:foreach or cmd:foreachkey to select/filter them right. The filters specified as the values of the cmd:foreach and cmd:foreachkey attributes are Perl expressions that expect to find the key/index in $_, I'll have to provide access to the value or the whole array/hash as well so that you could filter using the values, butI think it should handle any combination of references. Provided that the data structure is consistent. That is, if it's an array of hashes of something then the value of the key {Foo} in all hashes has the same type.

Plus actually there is no reason why couldn't the cmd:foreach handle plain scalars the same way as a ref to a one element array.

Genius. !! But now the question becomes: What if you don't know the cmd:forkey(s) beforhand? I'm getting confused again. :-) I guess you could have a fallback catchall cmd:forkey

---

I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness

cmd:forkey is specifically for "include this tag/twig" for this/these tag(s). If you want to process all (or all except a few) you'd use cmd:foreachkey.

OTOH, I do assume the list of keys, or at least the list of keys to be handled differently, is known. Like in one of the examples, the {PageId} key is to become the value of the id="" attribute of the <page> tag and all others will end up in the <field> tags.

I assume both the structure of the data and the structure of the XML is known. This is not, "hey, here's some data, serialize it anyhow so that when you deserialize it again, I end up with the same data". It's rather "hey. I have the data in this structure and need to write them to XML in that structure so that they will accept it".

Jenda


Support Denmark! Defend the free world!