I'm trying to confront these two designs for a nodeset:
The first one for the context where I will apply it will provide me more flexibility but it's a problem with UaModeler's auto-generation of code, since having a InstanceDeclaration having an extra property that is not part of the TypeDefinition is not so OO-friendly, but it's totally fine on an OPC UA modelling rules perspective.
The second approach is more basic and simple and has got no problems with the code generation tool, but I would like to avoid it for some reasons.
Since I implemented these examples on Server-side (using .NET 4.5) and I managed to get what I want in both cases, my question is if on Client-side it's also feasible in both cases without any particular different in effort between the two options.
In particular while the second option on server-side was ready to use after code-generation, the first one had me to subtype the autogenerated class FunctionalGroupModel to FunctionalGroupModelWithExtraChildren so that it could have the property TheCustomVariableWeWantToAdd. So very little extra-effort to get the first option instead of the second one. I expect a little effort more on Client development as well but I have no expirience with that.
Thanks in advance,
baldo
Developing Clients dealing with InstanceDeclarations that have extra properties
Moderator: uasdknet
- baldo
- Hero Member
- Posts: 25
- Joined: 19 Nov 2019, 12:15
- Support Team
- Hero Member
- Posts: 3068
- Joined: 18 Mar 2011, 15:09
Re: Developing Clients dealing with InstanceDeclarations that have extra properties
Hello baldo,
There should not be any differences on client side. A client should call TranslateBrowsePathstoNodeIds to the NodeIds of the children. The BrowseName must be the same for both approaches.
There should not be any differences on client side. A client should call TranslateBrowsePathstoNodeIds to the NodeIds of the children. The BrowseName must be the same for both approaches.
Best regards
Unified Automation Support Team
Unified Automation Support Team