On 26.11.19 11:48, André Somers wrote:
>
> On 26/11/2019 08:56, Ulf Hermann wrote:
>>> We have some code that evaluates JS in custom QQmlContexts with certain
>>> "magic" context properties set (sort of like the "index" or "modelData"
>>> context properties in delegates like Repeater.delegate).
>>> Will something similar still be possible?
>> You should rephrase that as required properties on actual objects. Then
>> the magic won't work anymore and you'll have to look up the properties
>> by ID of the object, but that is a good thing. It will improve
>> re-usability of your components.
> Lookup by ID? You mean set the object name like you did in your
> example in your talk at QtWS? I protested then, and I will protest now
> again. Don't. Really: don't. If you are talking about re-usability and
> maintainability of your code elsewhere, then advocating this practice
> is really wrong. You need to layer your QML on top of an API provided
> by C++, not poke into your QML from C++.
We're drastically improving the ability to layer QML on top of an API
provided by C++. It means that we need to know what that C++ API looks
like when looking at the .qml file without running it, for example when
linting. This is why we're moving to the model of declarative C++ type
registration and extraction of the "moc visible" API (slots, properties,
etc.) at build time. That way we can give you feedback that perhaps
you've accidentally used the wrong name of a C++ backed property at
build (or editing time), instead of through "returning undefined" at
run-time when accessing it.
>>
>> We're also changing the way views and delegate work. If you want to use
>> the "index" in a Repeater's delegate you'll have to declare that in QML
>> 3, using a required property:
>>
>> Repeater {
>> model: 10
>>
>> Text {
>> required property int index
>> text: "item " + index
>> }
>> }
>
> I really, really dislike this change. It looks even more like magic
> than what we have today. By all means deprecate/get rid off looking up
> without using `model.` in front of index, but what you write there
> really looks like magic. It is totally unclear who is setting a
> property (required or not) if you just declare it. This introduces
> more magic instead of less, and would IMO lead to more knowledge
> required in on the C++ side about the QML side of the application,
> where I just argued above that that leads to bad practice.
>
You say that it's unclear who is setting a (required) property. The
analogy that we've used is that required properties are like declaring
function parameters - you expect the caller to provide them, but you
don't really care where the caller provided them from. Think of the
above text delegate like a factory function (except that the parameters
are live bindings):
(pseudo code)
function createDelegate(index: int) {
return new Text("item " + index);
}
That doesn't feel like magic to me.
Simon
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
