Make values temporarily readonly

[Iucimhub]

Is your feature request related to a problem? Please describe.
Imagine we have pydase app which controls a airplane cockpit. If we turn on a routine called 'auto-pilot', it would be great that we can set all properties related to manual steering of the airplane to be read-only. Once 'autopilot' is disengaged, those properties should be writable again

Describe the solution you'd like
Allow the user to temporarily set certain object to be read-only (i.e. grey-out the corresponding box).

Describe alternatives you've considered
Hope that the user is clever enough not to change parameters that he is not supposed to change.

[mosmuell]

One could implement a decorator that specifies the trigger and the target properties that will be toggled (to be read-only). It could look like this:

import pydase


class MyService(pydase.DataService):
    def __init__(self) -> None:
        super().__init__()
        self._trigger_button = True

    @property
    def trigger_button(self) -> bool:
        """The trigger_button property."""
        return self._trigger_button

    @trigger_button.setter
    @trigger_readonly(event="event_name")
    def trigger_button(self, value: bool) -> None:
        self._trigger_button = value

    @property
    def toggled_property(self) -> float:
        """The toggled_property property."""
        return self._toggled_property

    @toggled_property.setter
    @trigger_readonly(on="event_name")
    def toggled_property(self, value: float) -> None:
        self._toggled_property = value


if __name__ == "__main__":
    service_instance = MyService()
    pydase.Server(service_instance).run()

This decorator could be used across all nested class instances, as well.

Implementation

The decorator needs to be put on the setter function. This makes sure that only the read-only state of properties that can be set can be toggled. The decorator would add a protected attribute to the property specifying the event (either triggering the event or being triggered by the event). The core-logic of triggering the read-only state would happen in the observer (DataServiceObserver). This would involve

• a function that collects the metadata from the properties (will be called when initialising the observer -> this will be static then)
• a callback that sends notifications as soon as the event was triggered. The notifications will take the cached state of the (toggled) properties and send it with a toggled read-only value.

Alternatives

One could also imagine to handle the read-only functionality directly in the browser. The main reasons for not doing this are:

• Client-Side Inconsistency and Decentralized Control: Managing the read-only state in the browser creates inconsistencies across different clients, such as Python scripts or other web clients, since these states are not synchronized with the backend (no single source of truth, no separation of concerns)
• Potential Security Concerns: Client-side controls are generally more vulnerable to manipulation. Users might be able to bypass the "read-only" restrictions, which could lead to unauthorized actions if not properly handled by the server.