[Qt-qml] How to think about Attached Properties?

[bea.lam at nokia.com]

Hi Charley,

> 
> In the case where I have MyAttachedProperties, must the nested "b.c.d" actually be nested within each other (with each of "b" and "c" derived from QObject and exposed to QML), or is there a way I could "map" the "b.c.d" to some application-specific attribute within MyAttachedProperties?  (For example, if "MyAttachedProperties" is merely a wrapper to expose an existing application-specific type with rich nested state, it would be nice to merely expose its state through a single top-level MyAttachedProperties wrapper.)
> 
> Specifically, does attached properties *demand* that each of "b" and "c" are derived from QObject?

Yes, the b.c.d notation is for Qt Property access, so "b" and "c" must be QObject-derived.


> 
> A "high-level" question is that since MyAttachedProperties is *already* derived from QObject (required to be attached properties), I could in my constructor set state through the meta-object system:
> 
>   MyAttachedProperties::MyAttachedProperties()
>   {
>      setProperty("myvalue", 42);
>   }
> 
> Or, I could have a *data member* that tracks this state, and expose it as a property:
> 
> class MyAttachedProperties
> {
>   Q_PROPERTY(int myvalue READ myvalue WRITE setMyvalue)
>   int myvalue;
> };
> 
> ...would either be accessed from QML, or is there a preference (would only one work, or hold preference over the other)?  (Yes, I see Q_PROPERTY adds type safety.)

Only the second one. Properties that have not been defined with Q_PROPERTY aren't supported in QML, since it relies on property type information.


> Finally, what about "name collisions"?  If I define an application-specific property like "width" that happens to "overlap" things that might be in the meta-object system, does one replace the other?

I'm not sure on the rules, but from experimentation it seems that if a subclass has a property with the same name as one in the base class, the inherited property becomes hidden.


> Back to the original thread on attached properties, I'd *like* to implement a single QObject "wrapper" of an application-specific type with (deep) state, and make that available to QML (as attached properties on some other C++ QML-exposed class).  Since the state is "deep", the "a.b.c.d" syntax would be great for access.
> 
> Is this one kind of intended use for "attached properties" (centralized wrapper-exposure of application-specific state, uncoupled from a given application-specific type)?
> 
> Another option would be to merely expose a QObject-derived class explicitly at each level for "a.b.c.d", and not use attached properties at all.

Yes, I guess that is one way of using attached properties. It sounds like it may make sense for your situation as the object does not normally have that type of property but the application state data can be annotated to the object.  I'd also consider using context properties to access application state data, as that can also be used to access some sort of b.c.d nested property value.


regards,

Bea