FAQ
Hello,

I'm working on a modification of xml package to allow me to implement
UnmarshalXML while it is not currently available. I'm hoping that the
API I'm imagining should be pretty close to what will be part of Go1.1
to avoid having to rewrite too much client code when that comes out.

The approach is to use the same infrastructure for providing data to
fields specifying innerxml. At the moment, I have a working
interface-based unmarshaler that uses an fInterface that flags saving in
the same way that fInnerXML does (but does not restrict on tag as
fInnerXML does). For those interested the CL is here
https://codereview.appspot.com/7396053

What I'm wondering (and this may be
the deal breaker for this approach): Will the inner XML be available to
a field that is not a struct. To clarify (from the xml Unmarshal
example):

// Type T is a type that satisfies xml.Unmarshaler interface.

type Email struct {
Where string `xml:"where,attr"`
Addr T // This field receives a []byte of the inner XML.
}
type Address struct {
City, State string
}
type Result struct {
XMLName xml.Name `xml:"Person"`
Name string `xml:"FullName"`
Phone string
Email []Email
Groups []string `xml:"Group>Value"`
Address
}

This give me the expected behaviour, the innerxml for the <Email>
element is sent to (*T).UnmarshalXML and handled correctly.

What I'm wondering is about this. I have my fInterface flag set on the
Result.Email field below:

type Address struct {
City, State string
}
type Result struct {
XMLName xml.Name `xml:"Person"`
Name string `xml:"FullName"`
Phone string
Email T // This field receives a []byte of the inner XML.
Groups []string `xml:"Group>Value"`
Address
}

Because I'm using the fInnerXML saveXML store, Email gets sent the inner
XML for Result (this is expected) and only one field that is an
Unmarshaler can exist in any single struct (also expected).

These two things mean that while it works at the moment, it restricts
the shape of data structures that use it: one Unmarshaler per struct,
and slices only in structs (i.e. no ">" sub-element specification).

I'm wondering if people think this is going to be a productive path,
since I don't really want to waste time on this if it's going to lead to
a dead end.

Please note, I'm not proposing this as a working toward a solution for
the core, just something as a stop gap for my own code while the
standard library xml Unmarshaler code is not done.

thanks
Dan

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dan Kortschak at Feb 22, 2013 at 2:00 am

    On Fri, 2013-02-22 at 11:02 +1030, Dan Kortschak wrote:
    These two things mean that while it works at the moment, it restricts
    the shape of data structures that use it: one Unmarshaler per struct,
    and slices only in structs (i.e. no ">" sub-element specification).
    This now works with sub-element specification.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 22, '13 at 12:33a
activeFeb 22, '13 at 2:00a
posts2
users1
websitegolang.org

1 user in discussion

Dan Kortschak: 2 posts

People

Translate

site design / logo © 2022 Grokbase