Log In
Register
Forum
Topic RSS
12:42, EET
October 21, 2019
Offline
Hey,
we have a use case where we have a basic information model and a reference implementation for this model, both as nodesets (and both created in ua modeller). I have no problem creating the codegen classes and loading both model and impl in a sample server type application and viewing the server in UaExpert. So far so good. The information model specifies methods for some of the specified types, and now I’m wondering where the best place is to implement these methods, especially since the server structure is not created programmatically but is loaded from XML. From my understanding i have to possibilites:
– implementing the methods directly in the codegen classes of the information model
– implementing the methods in their own classes and then using the static setters for every Object that needs the impl (so basically once for every method) after loading the server
Are my assumptions correct? Are there any other/better ways?
What is the best practive or preferred way? The Codegen- and server tutorial explanations are not exactly extensive regarding this topic and i think a little extra work in the tuorials would go a long way (server tutorial 13.2.5 is about this topic, but a llitle bit more info would be really great, maybe a code snippet that shows more then just a method signature with the info “implemt the method here”.
Anyway, thanks for any answer, much appreciated.
Best regards,
Florin
14:48, EET
April 3, 2012
Offline
Hi,
Depends on what you count, we do also have the way we had before Codegen, see MyMethodManagerListener in the sampleconsoleserver, but it is a bit more pain to use.
Also, the documentation could be better. You can push the implementations via the setXXXMethodImplementation also before loading the model.
In general this is a complicated topic. There is no best way, because it depends on what you want to do and how. Personally nowadays I would prefer to avoid changing generated files manually (too bad java doesn’t have partial classes the same way as C# has, we sort of emulate this with the 2 outputs per type, but it is not the same), thus the setXXXMethodImplementation way. This way you can also add an implementation to the core namespace types, as we have already generated and use that as part of the SDK (i.e. the code is already compiled). Though, if you would need any extra info you cannot like store it as a field in the class this way.
In a generic case I believe just having the signature is basically almost the best we can do in the generation, because we cannot know anything what the method would do (if we would there would be no need to write the implementation manually). But we could probably add some more in-depth example of using the SampleTypes.xml generation outputs, it currently serves more like this is how to use Codegen -sample, not exactly using the generated sources after that.
11:29, EET
October 21, 2019
Offline
Ok, i also thought editing the generated classes directly seems not the right way, but using the static setters works pretty well after trying it out. So thanks for your response. Dont get me wrong, I think the tuturials are great and they have helped me a lot, it is just the codegen stuff that is lacking (maybe it is more my knowledge that is lacking). I understand that it is an incredible complex topic. I think your idea with using the sampleTypes.xml is a good one.
Thanks again.
Best regards
11:51, EET
April 3, 2012
Offline
(I think this is missing from the manual, should probably be added..)
If you would happen to use a dependency injection framework that allows injecting to static setters (e.g. like with Google Guice, https://github.com/google/guice), you can add:
<staticMethodAnnotations>
<staticMethodAnnotation>com.google.inject.Inject</staticMethodAnnotation>
</staticMethodAnnotations>
</enhancements>
in the Codegen configuration. Then those method handler setters would be annotated with the given annotations.
(or I guess nowadays the more standard JSR-330 annotation would be used instead)
and have
(the the Guice module configure method; you would also bind the method implementation interface to an implementation etc.)
The methods handlers are in the XXXTypeNodeBase, which XXXTypeNode extends. We tried to emulate C# partial classes such as that the TypeNodeBase contains all logic and can be easily regenerated. Doesn’t matter here, but might be important (not sure does the requestStaticInjection work via XXXTypeNode in this case or only via XXXTypeNodeBase, though technically static methods are visible in subclasses, that is why the interface names are XXXTypeNameYYYMethodNameMethod).
This may or may not be useful, but one of our own app does it like that.
Most Users Ever Online: 1919
Currently Online:
12 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 735
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
