Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add XMLName field to generated structs #142

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

SoMuchForSubtlety
Copy link

Without this PR, marshalling a struct generated by xsdgen will not set it's name and namespace correctly. As fas as I can tell the standard practice in go is to add the field XMLName of type xml.Name to structs you want to marshal to XML. That fiel's tag will then be used for setting the elements name and namespace.

see https://pkg.go.dev/encoding/xml#Marshal

This field will be used  by xml.Marshal for setting the element name,
see https://pkg.go.dev/encoding/xml#Marshal
@SoMuchForSubtlety SoMuchForSubtlety marked this pull request as draft August 8, 2021 16:01
@SoMuchForSubtlety
Copy link
Author

I just realized, that this should only be done for top level elements. I'll need to figure out how to determine that at the code generation stage.

@jimidle
Copy link

jimidle commented Mar 22, 2022

I think you need to manually create a top level struct with the XMLName xml.Name field and embed the top level structure you want to unmarshall using that

@john8329
Copy link

The problem with identifying root structs is non-trivial, any edit to the Element struct will make the code fail in spectacular and obscure ways. For now I implemented it by keeping a list of root names, returning it from Normalize() and handling it later during code generation with some code from this parser. Does it solve my problem? No, since for structs where both XMLName and xml:"name" are defined it produces an error. My solution was to implement XMLName in root structs but leave it empty and fill it in the app code if needed. Yes it's very use case specific, but this is to say that a generic solution might not fit everyone's needs and might break code unless put behind a feature flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants