Net-XMPP

 view release on metacpan or  search on metacpan

lib/Net/XMPP/Namespaces.pm  view on Meta::CPAN

Now this is where this starts to get a little sticky.  When you see a
namespace with __netxmpp__, or __netjabber__ from Net::Jabber, at the
beginning it is usually something custom to Net::XMPP and NOT part of
the actual XMPP protocol.

There are some places where the structure of the XML allows for
multiple children with the same name.  The main places you will see
this behavior is where you have multiple tags with the same name and
those have children under them (jabber:iq:roster).

In jabber:iq:roster, the <item/> tag can be repeated multiple times,
and is sort of like a mini-namespace in itself.  To that end, we treat
it like a separate namespace and defined a __netxmpp__:iq:roster:item
namespace to hold it.  What happens is this, in my code I define that
the <item/>s tag is "item" and anything with that tag name is to create
a new Net::XMPP::Stanza object with the namespace
__netxmpp__:iq:roster:item which then becomes a child of the
jabber:iq:roster Stanza object.  Also, when you want to add a new item
to a jabber:iq:roster project you call NewQuery with the private
namespace.

I know this sounds complicated.  And if after reading this entire
document it is still complicated, email me, ask questions, and I will
monitor it and adjust these docs to answer the questions that people
ask.

=head2 add_ns()

To repeat, here is an example call to add_ns():

    add_ns(ns    => "mynamespace",
            tag   => "mytag",
            xpath => {
                      JID       => { type=>'jid', path => '@jid' },
                      Username  => { path => 'username/text()' },
                      Test      => { type => 'master' }
                     }
           );

ns - This is the new namespace that you are trying to add.

tag - This is the root tag to use for objects based on this namespace.

xpath - The hash reference passed in the add_ns call to each name of
entry tells Net::XMPP how to handle subsequent GetXXXX(), SetXXXX(),
DefinedXXXX(), RemoveXXXX(), AddXXXX() calls.  The basic options you
can pass in are:

type - This tells Stanza how to handle the call.  The possible values are:

           array - The value to set and returned is an an array
                   reference.  For example, <group/> in jabber:iq:roster.

           child - This tells Stanza that it needs to look for the
                   __netxmpp__ style namesapced children.  AddXXX() adds
                   a new child, and GetXXX() will return a new Stanza
                   object representing the packet.

           flag - This is for child elements that are tags by themselves:
                  <foo/>.  Since the presence of the tag is what is
                  important, and there is no cdata to store, we just call
                  it a flag.

           jid - The value is a Jabber ID.  GetXXX() will return a
                 Net::XMPP::JID object unless you pass it "jid", then it
                 returns a string.

           master - The GetXXX() and SetXXX() calls return and take a
                    hash representing all of the GetXXX() and SetXXX()
                    calls.  For example:

                      SetTest(foo=>"bar",
                              bar=>"baz");

                    Translates into:

                      SetFoo("bar");
                      SetBar("baz");

                    GetTest() would return a hash containing what the
                    packet contains:

                      { foo=>"bar",  bar=>"baz" }

           raw - This will stick whatever raw XML you specify directly
                 into the Stanza at the point where the path specifies.

           scalar - This will set and get a scalar value.  This is the
                    main workhorse as attributes and CDATA is represented
                    by a scalar.  This is the default setting if you do
                    not provide one.

           special - The special type is unique in that instead of a
                     string "special", you actually give it an array:

                       [ "special" , <subtype> ]

                     This allows Net::XMPP to be able to handle the
                     SetXXXX() call in a special manner according to your
                     choosing.  Right now this is mainly used by
                     jabber:iq:time to automatically set the time info in
                     the correct format, and jabber:iq:version to set the
                     machine OS and add the Net::Jabber version to the
                     return packet.  You will likely NOT need to use
                     this, but I wanted to mention it.

           timestamp - If you call SetXXX() but do not pass it anything,
                       or pass it "", then Net::XMPP will place a
                       timestamp in the xpath location.

     path - This is the XPath path to where the bit data lives.  The
            difference.  Now, this is not full XPath due to the nature
            of how it gets used.  Instead of providing a rooted path
            all the way to the top, it's a relative path ignoring what
            the parent is.  For example, if the "tag" you specified was
            "foo", and the path is "bar/text()", then the XPath will be
            rooted in the XML of the <foo/> packet.  It will set and get
            the CDATA from:

               <foo><bar>xxxxx</bar></foo>



( run in 1.346 second using v1.01-cache-2.11-cpan-63c85eba8c4 )