@pspeed said:
Yes, in those rare cases where they would be required.
Can we take a step back for a moment and talk about the use-case you have in mind that wasnât handled by default introspection?
Well, my personal use case is as follows:
A custom control that has a field called behaviour, or even a list of behaviours.
Each of these behaviours would then have to be configured in the scene composer, unless provided via external resources such as configuration scripts and so on.
For this, I need a property editor that will allow me to select from a list of available behaviour classes so that I can add them to the list.
The behaviours themselves are Savables that have either none or multiple properties.
As such, the behaviour classes represent components and the control itself is a composite of these components.
And for each of these behaviour classes I need either a generic editor or a specialized editor, for example one that is able to select nodes from the currently edited scene and so on.
While the control itself is responsible for handling the events emitted by these behavioural components and thus for updating the presentation based on the state information purported by these events, the behavioural components would operate on the game model alone.
As I do not want to put that information into the code, I looked for a way of making this information editable via the scene composer as either user data or in form of savables such as controls. Therefore I require the SDK to support more property editors than what is currently available, and to also support different property editors for the same type in different contexts.
I still do not know whether BeanInfo will suffice for meeting my âdifferent context, different property editorâ requirement, but I guess that if I use it carefully, it may suffice. In the worst case, I will end up with random property editors if I define the BeanInfo classes ambiguously, e.g. having multiple BeanInfo classes for the same type but in different packages. I guess that I will have to use subclasses and dedicated BeanInfo classes in order to make this happen.
The proposed annotation, as I see now, will not be able to save me from this dilemma. But I guess that subclassing and specialized BeanInfo classes might do the trick.
