-
Notifications
You must be signed in to change notification settings - Fork 948
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
Support Dynamic Complex Types #2146
Support Dynamic Complex Types #2146
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2146 +/- ##
==========================================
+ Coverage 57.90% 57.92% +0.01%
==========================================
Files 324 324
Lines 61826 61833 +7
==========================================
+ Hits 35801 35816 +15
+ Misses 26025 26017 -8
|
Hi @MarkusHorstmann , please elaborate how this extension can be used, or even better provide a test case / sample. I already cherry picked your bug fix, thanks! |
I have added test cases using a dynamic encodeable with simple type information (just a list of string-valued fields). For a realistic use case feel free to look at the CESMII NodeSet utilities. It is not meant to be a sample, though. |
Hi @MarkusHorstmann, looks pretty good, any idea why the tests are failing? |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please fix the test cases
The new tests should now run fine. There are two other tests failing (ReadOnDiscoveryChannel and AppVeyor build) that don't seem to be related to my changes, and I've seen them fail in other branches as well. Please let me know if you think otherwise. |
Oops, thought I was closing the review comment, not the PR. Reopened it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MarkusHorstmann, we discussed the changes today but some questions came up. We need to follow up in a seperate thread.
/// </summary> | ||
/// <returns>The xml qualified name for the type instance</returns> | ||
XmlQualifiedName GetXmlName(IServiceMessageContext context); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is unclear why the IServiceMessageContext is needed here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A IComplexTypeInstance implementation needs the Encodable Factory and the Namespace Table from the context. The reason is that the implementation may need to make additional nested types in a structure available via the Factory. Otherwise, all known types would have to be pre-registered, which largely defeats the purpose of a truly dynamic (= meta-data-driven) type implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mregen Please let me know if you need any additional information or maybe want to discuss on a call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MarkusHorstmann , we discussed the PR yesterday in the user group and it is accepted, just taking a final check then its ready to go. Thanks!
Hello, I'm interested about this feature. I have to create Structure Type (so ExtensionObject) XML from my autoDiscovery code. I am able to auto discover my StructureDefinition : `
` But now, how can I dynamically create an XML file and how to use it to decode my ExtensionObject when I read my variable using |
Hi, @gabrielgriesser! This Pull Request only provides the necessary hooks in the Core to make it possible implement dynamic types. I have implemented a dynamic type that I need in the context of a NodeSet editing tool, and it uses the editing tool's type system not the OPC SDK's type definition classes. The code is publically available here (https://github.com/cesmii/CESMII-NodeSet-Utilities/blob/main/src/CESMII.OpcUa.NodeSetModel.Factory.Opc/DynamicComplexType.cs). It should be relatively straightforward to change it to read the type information from a DataTypeDefinition instead of the NodeModel's DataTypeModel. I also implemented a test case that implements a rudimentary dynamic type that handles only string values. This could be another starting point. |
/// </summary> | ||
/// <returns>The xml qualified name for the type instance</returns> | ||
XmlQualifiedName GetXmlName(IServiceMessageContext context); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MarkusHorstmann , we discussed the PR yesterday in the user group and it is accepted, just taking a final check then its ready to go. Thanks!
@MarkusHorstmann please merge master into your PR, the ci VMs had been updated recently so the failing build will not pass otherwise and i can't merge. |
Complex Type support assumes that every OPC type is represented by exactly one .Net type, which in turn knows encoding ids, XML names etc. These changes enable use of a single type that implements encoding/decoding based on OPC type information at runtime.
Proposed changes
Complex Type support assumes that every OPC type is represented by exactly one .Net type, which in turn knows encoding ids, XML names etc.
These changes enable use of a single type that implements encoding/decoding based on OPC type information at runtime.
Related Issues
Types of changes
What types of changes does your code introduce?
Put an
x
in the boxes that apply. You can also fill these out after creating the PR.Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.