refactor to add 3.4 Multiple Items in Form Results

[LightZam]

XEP-0004, 3.4 Multiple Items in Form Results
http://xmpp.org/extensions/xep-0004.html#protocol-results

refactor :
add Fileld::parse to refactor QXmppDataForm::parse
add Fileld::toXml to refactor QXmppDataForm::toXml
add Media::parse to refactor QXmppDataForm::parse
add Media::toXml to refactor QXmppDataForm::toXml

new feature :
add Item, reported class to achieve XEP-0004 3.4
unit test for XEP-0004 3.4 Multiple Items in Form Results

[jlaine]

On the whole this looks good, though I will need to read it more in depth.

Georg: any thoughts on the non-const accessors? I understand the motivation, but we do not use them much in the rest of the API.

[LightZam]

but it will be needed in some of XEP Protocol like XEP-0055 Jabber Search

[LightZam]

it might not be super useful for other API,
but this PR is no harm for project, and it can be use on other protocol in the futures.
As I said, XEP-0055 Jabber Search was an example, and i will implement it.

ref: https://xmpp.org/extensions/xep-0055.html

[jlaine]

I am not entirely sure I understand the purpose of the Item / Reported classes. Unless I am mistaken, they both seem to describe a list/vector of Fields?

[LightZam]

yes, both of them described a list of fields, the difference between them is reported stand for "table haed" and item stand for "talbe cell".

reference:
the definition
http://xmpp.org/extensions/xep-0004.html#protocol-results
the example
https://xmpp.org/extensions/xep-0055.html#example-9

[jlaine]

OK I guess my question was: do we need two separate classes for this?

[LightZam]

there is a little different xml tag name and element between reported, item

if you would like it to use only item, it is possible, but there will be some specific logic for this kind purpose. it looks wired to me.

like below

 "<x xmlns=\"jabber:x:data\" type=\"result\">"
            "<reported>"
                "<field type=\"jid-single\" label=\"JID\" var=\"jid\"/>"
                "<field type=\"text-single\" label=\"Username\" var=\"Username\"/>"
                "<field type=\"text-single\" label=\"Name\" var=\"Name\"/>"
                "<field type=\"text-single\" label=\"Email\" var=\"Email\"/>"
            "</reported>"
            "<item>"
                "<field type=\"text-single\" var=\"jid\">"
                    "<value>[email protected]</value>"
                "</field>"
                "<field type=\"text-single\" var=\"Username\">"
                    "<value>Zam</value>"
                "</field>"
                "<field type=\"text-single\" var=\"Name\">"
                    "<value>Zam</value>"
                "</field>"
                "<field type=\"text-single\" var=\"Email\">"
                    "<value>[email protected]</value>"
                "</field>"
            "</item>"
        "</x>"

[LightZam]

@jlaine
if you are having any considering or suggestion, please shoot to me.
it would be great to have that.

[jlaine]

OK so "reported" has "label" but no "value", right? Let's keep the classes separate then.

[LightZam]

yes, it is

[jlaine]

Could you please address my question: can't we use "Item" class for the "reported" member ?

[tehnick]

Georg: any thoughts on the non-const accessors? I understand the motivation, but we do not use them much in the rest of the API.

@0xd34df00d ^^^

[jlaine]

Could we re-push this branch to get coverage to run please? Also does doc/xep.doc need updating?

[0xd34df00d]

@tehnick re non-const getters — I'm generally fine with them if they're providing direct access to some d-proxied field (and if that field is not involved in any invariants of the class), but, indeed, the consistency with the rest of the API is also important. I'd probably drop them.