Is there a fancy XML term for "all the children of an element?" I keep thinking of writing "the body of the stanza will be …" but I feel like body is a loaded term because it's an actual element in messages
MattJ
innerHTML
MattJ
(you're welcome)
Guus
child elements?
Guus
child nodes?
Guus
decendants?
Sam Whited
I should have seen innerHTML coming; innerXML maybe? Decendants might be a good word, thanks. I don't know why, but writing "all the child elements of the stanza" sounded weird
MattJ
"the contents of the stanza will be"?
Zash
There's also "payloads"
Sam Whited
Actually, I don't know why I didn't think of that, payloads is what I was using elsewhere so I should probably apply it here too for consistency
Sam Whited
I'm still having the hardest time figuring out a nice way to write handlers for vairous stanza types; for IQ elements the handler takes a representation of the IQ which can be used to get attributes on it, reply to it, etc. and then the token stream of the payload and the start token that triggered the handler so you can do whatever you do to decode the payload into a struct, or just pop tokens and use it as is, etc.
debaclehas left
pulkomandyhas left
jonas’
Sam Whited, descendants are also the term used by XPath et al
jonas’
though I think it’s recursive and doesn’t only apply to direct children
jonas’
so children should work
Sam Whited
For message and presence though where there might be multiple payloads that depend on eachother (eg. if you trigger on "messages with a body" you probably also want to know if it has a no-copy hint or something) you end up having to provide the entire token stream of the message including the message start element (which feels inconsistent from the IQ handlers)
Sam Whited
Yah, the term is just weird because providing children or decendents sounds like I'm providing some representation of the entire element, where really I'm just providing a way to stream XML tokens