Let’s continue reexporting jid and minidom, but not their inner pub
items, users of this crate can go one level deeper if they need that.
Only xso::error::Error is still useful to reexport, as this is part of
the public API of all of our parsers.
Analogous to the already existing `IntoXml` implementation helpers
based on an `Into<Element>` implementation on a type, this provides
the utilities for `AsXml`.
This is of course exceptionally inefficient, but it is only needed
transitionally until we have everything migrated to derive macros or
otherwise rewritten in terms of AsXml/FromXml.
This will soon replace the IntoXml trait. The idea here is that we
don't generally need to take ownership of values which are going to
be transformed into XML: most of the time, the XML text is created
by building a string from some more specific type, such as an
integer or an enum. Requiring to clone an entire structure for this
purpose is wasteful.
In other cases, we actually could reference data right from the structs
we are converting to XML. In those cases, assuming that an iterator
always generates owned data would be incorrect, too.
Hence, we introduce a new `Item` type which closely mirrors the
`rxml::Item` type, but where the constituents are `Cow`. In the upcoming
changes, we are going to work toward replacing all uses of `IntoXml`
with `AsXml`, as well as modifying the macros accordingly.
Paths are already patched in the workspace's [patch.crates-io] block.
Not sure why this was added in the first place.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
By defining the variables in the parent scope, we can avoid one level of
indentation for the tuple, which makes things more readable.
Additionally, we don’t need to call .to_str() on the passed objects,
they automatically Deref to &str for the format!() call.
This depends on XEP-0313 for its MAM metadata, and many others such as
XEP-0198, XEP-0280 and XEP-0352 for the inline features, but we
currently provide those as minidom Elements instead.
Text codecs allow to customize the conversion of data from/to XML,
in particular in two scenarios:
1. When the type for which the behaviour is to be defined comes from a
foreign crate, preventing the implementation of
FromXmlText/IntoXmlText.
2. When there is not one obvious, or more than one sensible, way to
convert a value to XML text and back.
Previously, we only enforced the existence of at most one `#[xml(text)]`
field only at code generation time for `FromXml`. This change enforces
it at parsing time, which is more consistent and allows for a clearer
error message.
