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

Use custom {de,}serialization for operation/response envelopes #5

Closed
wants to merge 7 commits into from

Conversation

leftmostcat
Copy link
Collaborator

This allows for creating a strongly-typed link between an operation and its associated response, rather than forcing consumers to match on enums when only a single variant is possible without error.

This allows for creating a strongly-typed link between an operation and
its associated response, rather than forcing consumers to match on enums
when only a single variant is possible without error.
@leftmostcat leftmostcat marked this pull request as ready for review April 16, 2024 18:23
where
A: serde::de::MapAccess<'de>,
{
match map.next_key::<String>()? {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, we should never be receiving more than one element in the body of a response. That said, there's no documented guarantee of this that I'm aware of, so this code could potentially be made more robust by iterating next_key() until it gave us None and deserializing the expected body if we find it, logging any unexpected elements, and erroring if we never find it. Would appreciate thoughts on this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understood the the documentation the inner body response is considered a collection?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A quick scan through the WSDL suggests that the contents of the soap:Body will always be exactly one element.

Comment on lines +38 to +41
pub trait EnvelopeBodyContents {
/// Gets the name of the element enclosing the contents of this
/// structure when represented in XML.
fn name() -> &'static str;
Copy link
Collaborator Author

@leftmostcat leftmostcat Apr 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deriving this would be pretty trivial and we probably want to do that soon. I just wanted to get it working.

For derivation, we could even potentially make it so that Operation and OperationResponse are the traits used for the macro(s) and getting EnvelopeBodyContents is a "hidden" bonus. It would just require that we add something like a #[response(GetFolderResponse)] attribute to the Operation derive. Thoughts on this are welcomed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps something more specific to the project such as #[ews:node(GetFolderResponse)] ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the helper attribute needs to be a valid identifier, but that's something we can figure out later if we do want to add this derive functionality in that form.

Copy link
Contributor

@ikeycode ikeycode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reiterate, I really do like this change :]

Copy link
Member

@babolivier babolivier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me as well, I just have a couple of nitpicks.

src/types/soap/de.rs Outdated Show resolved Hide resolved
src/types/soap/de.rs Outdated Show resolved Hide resolved
@leftmostcat
Copy link
Collaborator Author

Merged.

leftmostcat added a commit that referenced this pull request Apr 17, 2024
@leftmostcat leftmostcat deleted the strong-operation-response branch April 17, 2024 18:48
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