Tango class with pogo :Dynamic attributes

# 3 years ago
Olivier Neveu	Hello Dear All, I have a question and I searched a bit for an answer but so far without success. By reading this page, it seems that the "add_<Dyn attr class name>_dynamic_attribute(string att_name)" call can only be made from the "void DynAttr::add_dynamic_attributes()" method. But I tested to call the "add_…" and "remove_<Dyn attr class name>_dynamic_attribute(string att_name)" method elsewhere and it seems to work just fine. So this is "legal" or can we only call "add_<Dyn attr class name>_dynamic_attribute" from the "add_dynamic_attributes()" method ? I don't know if I'm clear ? Best regards, Olivier Neveu

# 3 years ago

Hello Dear All,

I have a question and I searched a bit for an answer but so far without success.
By reading this page, it seems that the "add_<Dyn attr class name>_dynamic_attribute(string att_name)" call can only be made from the "void DynAttr::add_dynamic_attributes()" method.

But I tested to call the "add_…" and "remove_<Dyn attr class name>_dynamic_attribute(string att_name)" method elsewhere and it seems to work just fine.

So this is "legal" or can we only call "add_<Dyn attr class name>_dynamic_attribute" from the "add_dynamic_attributes()" method ?

I don't know if I'm clear ?

Best regards, Olivier Neveu

# 3 years ago
Reynald	Hi Olivier, As you noticed, these methods can be invoked from elsewhere. It is a recommendation to create the attributes in add_dynamic_attributes() method because it is a method which is invoked by some POGO generated code in some specific situations. This POGO code is also relying on that in order to do some cleanup when some reinitializations occur. But this add_dynamic_attributes method is recommended in the use case when the dynamic attributes need to be created after the device initialization (properties read) and before exporting the device but there are some other use cases where dynamic attributes will need to be created at a later stage. If you create your dynamic attributes somewhere else, if you're not careful enough, you might encounter some issues when invoking the INIT command, invoking "Restart Device" from jive for instance. It really depends on your use case. But remember to test the behaviour of your device server when invoking the INIT command, invoking the RestartServer and DevRestart commands from your admin device because the POGO generated code might remove some of your dynamic attributes in these cases (but this might be what you want). You should test these use cases. There is some code in the POGO generated code which will take care of removing dynamic attributes in some use cases before recreating them. You can have a look at YourClass::device_factory method in YourClassClass.cpp file for instance. So you can use these "add_…" and "remove_<Dyn attr class name>_dynamic_attribute(string att_name)" methods from where you want but be sure to test all the edge cases because it might cause you some troubles if you're not careful enough. Hoping this helps. Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 3 years ago

Reynald

Hi Olivier,

As you noticed, these methods can be invoked from elsewhere.
It is a recommendation to create the attributes in add_dynamic_attributes() method because it is a method which is invoked by some POGO generated code in some specific situations.
This POGO code is also relying on that in order to do some cleanup when some reinitializations occur.

But this add_dynamic_attributes method is recommended in the use case when the dynamic attributes need to be created after the device initialization (properties read) and before exporting the device but there are some other use cases where dynamic attributes will need to be created at a later stage.

If you create your dynamic attributes somewhere else, if you're not careful enough, you might encounter some issues when invoking the INIT command, invoking "Restart Device" from jive for instance.

It really depends on your use case. But remember to test the behaviour of your device server when invoking the INIT command, invoking the RestartServer and DevRestart commands from your admin device because the POGO generated code might remove some of your dynamic attributes in these cases (but this might be what you want). You should test these use cases.

There is some code in the POGO generated code which will take care of removing dynamic attributes in some use cases before recreating them. You can have a look at YourClass::device_factory method in YourClassClass.cpp file for instance.

So you can use these "add_…" and "remove_<Dyn attr class name>_dynamic_attribute(string att_name)" methods from where you want but be sure to test all the edge cases because it might cause you some troubles if you're not careful enough.

Hoping this helps.
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 3 years ago
Olivier Neveu	Hi Reynald, thank you for this detailed answer. This will help me a lot. I have some questions / remarks : Invoking RestartServer in Jive indeed removes the dynamic attributes. So as you say, it is ok. I don't know why but : invoking init in atkpanel doesn't seem to do anything. When I call init from an another client (with the "command_inout" method), I don't notice any change either. I don't fully understand why it might be interesting to create the dynamic attributes before exporting the device but I think I don't need this information just yet. Thanks again. Best regards, Olivier

# 3 years ago

Olivier Neveu

Hi Reynald,

thank you for this detailed answer. This will help me a lot.

I have some questions / remarks :
Invoking RestartServer in Jive indeed removes the dynamic attributes. So as you say, it is ok.

I don't know why but : invoking init in atkpanel doesn't seem to do anything. When I call init from an another client (with the "command_inout" method), I don't notice any change either.

I don't fully understand why it might be interesting to create the dynamic attributes before exporting the device but I think I don't need this information just yet.

Thanks again.
Best regards, Olivier

# 3 years ago
Reynald	Olivier Neveu I don't know why but : invoking init in atkpanel doesn't seem to do anything. When I call init from an another client (with the "command_inout" method), I don't notice any change either. I think if you invoke the init command, it will simply call always_executed_hook() followed by delete_device() and init_device(). add_dynamic_attributes() is not called in this case. You can start your device server with -v4 option to see the DEBUG logs. Then you'll see what methods are executed. Olivier Neveu I don't fully understand why it might be interesting to create the dynamic attributes before exporting the device but I think I don't need this information just yet. The main interest is that as soon as your device is accessible/available for any client, a generic client can deduce the correct interface (including all the dynamic attributes) immediately. If dynamic attributes are created after the export phase, already started generic clients will have to rely on InterfaceChange events to be aware of the new attributes. As far as I know, most of the classical generic clients like atkpanel do not use InterfaceChange events (yet). So this means that your new attributes won't be visible on already started generic clients. You will need to restart a new instance of such generic client to be able to interact with the dynamic attributes created after the export phase. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 3 years ago

Reynald

Olivier Neveu
I don't know why but : invoking init in atkpanel doesn't seem to do anything. When I call init from an another client (with the "command_inout" method), I don't notice any change either.

I think if you invoke the init command, it will simply call always_executed_hook() followed by delete_device() and init_device().
add_dynamic_attributes() is not called in this case.
You can start your device server with -v4 option to see the DEBUG logs. Then you'll see what methods are executed.

Olivier Neveu
I don't fully understand why it might be interesting to create the dynamic attributes before exporting the device but I think I don't need this information just yet.

The main interest is that as soon as your device is accessible/available for any client, a generic client can deduce the correct interface (including all the dynamic attributes) immediately.
If dynamic attributes are created after the export phase, already started generic clients will have to rely on InterfaceChange events to be aware of the new attributes.
As far as I know, most of the classical generic clients like atkpanel do not use InterfaceChange events (yet).
So this means that your new attributes won't be visible on already started generic clients.
You will need to restart a new instance of such generic client to be able to interact with the dynamic attributes created after the export phase.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 3 years ago
Olivier Neveu	Hello Reynald, thank you again. It is very clear. I tested both subjects : the "init" command and the "InterfaceChange" event. Both works as expected. I will try to do my best to use your information and recommendations. Best regards, Olivier