[Interest] Define map of static items in QML

[Elvis Stansvik]

2016-03-30 11:08 GMT+02:00 Gianluca <gmaxera at gmail.com>:
>
> Il giorno 30/mar/2016, alle ore 09:46, Elvis Stansvik <elvstone at gmail.com> ha scritto:
>
>> Hi Gianluca,
>>
>> 2016-03-30 10:16 GMT+02:00 Gianluca <gmaxera at gmail.com>:
>>>
>>> Il giorno 30/mar/2016, alle ore 07:43, Elvis Stansvik <elvstone at gmail.com>
>>> ha scritto:
>>>
>>> Den 30 mar 2016 8:36 fm skrev "Elvis Stansvik" <elvstone at gmail.com>:
>>>>
>>>> Hi all,
>>>>
>>>> I can understand why I can do
>>>>
>>>> property Item foo: Foo {}
>>>> property Item bar: Bar {}
>>>> property variant items: {
>>>>    "foo": foo,
>>>>    "bar": bar
>>>> }
>>>>
>>>> but not
>>>>
>>>> property variant items: {
>>>>    "foo": Foo{},
>>>>    "bar": Bar{}
>>>> }
>>>>
>>>> The first opening { in the second example probably puts me in JS
>>>> territory, where the Item {} syntax is not understood as a static definition
>>>> of an item.
>>>>
>>>> However, is there some way of defining a map of static items like this,
>>>> without having to bind the item instances to properties first? Such that I
>>>> can later do e.g. items["foo"] to access an item?
>>>
>>> I should state my use case as well: I'm doing a small page based embedded
>>> app (less than 20 pages), based on a StackView, where I'm thankfully not
>>> hardware constrained (it's a fast PC). So I have no reason to use Loader to
>>> load pages dynamically but was thinking of keeping them all statically in a
>>> map, so that I can switch page based on the name of the page (e.g
>>> "WelcomeScreen") by calling some function or perhaps emitting a signal with
>>> the name as argument.
>>>
>>> For this use cases (and others), I usually use one of the ObjectModel,
>>> DelegateModel or Package (or the older VisualDataModel). They are wonderful
>>> for creating models containing QML object and they can created as you want.
>>> Also DelegateModel can contains groups so you can filter them, and Package
>>> let you to name the items so you can access using dot syntax: views.foo,
>>> views.bar
>>> In your case, I will use DelegateModel and access using numeric index, but
>>> you can also explore Package and use the attached propertied Package.name to
>>> give a name to all the views.
>>
>> Thanks a lot for the suggestions.
>>
>> I must ask though. Why would you use a DelegateModel in my case? Would
>> you manage the name -> index mapping separately then? (to avoid
>> hardcoded indices throughout the code).
>>
>> I think I will go the Package route, the dot syntax seems like a nice
>> thing I can use.
>>
>> Elvis
>
> I think that the Package may be the best route for you, but I suppose it can be used only with a DelegateModel and not alone. And of course, I suggest you to give a try.

Alright. Althought I came to think of something: Will not Package
require me to define the items fully inside the Package? E.g. I would
have to have my screens all defined in the same file, like:

Package {
    WelcomeScreen {
        id: welcomeScreen
        Package.name: "welcomeScreen"
        ...
    }
    OtherScreen {
        id: otherScreen
        Package.name: "otherScreen"
        ...
    }
    ....
}

My screens will be quite complex, and I would want to keep them in
separate QML files :/ So if using Package requires me to have them all
inline like this, I'll have to find some other solution.

One idea I had was to abandon the idea with identifying screens by
their name as a string, and instead use a singleton (e.g. Screens.qml)
where I keep all the screens as properties, so I could do e.g.
Screens.welcomeScreen to refer to them. But I hit some trouble with
using multiple singletons (see my other most recent post to the list).

> The Package has been added recently, before the introducing of Package I used to use the Component.onCompleted to construct the name -> index mapping. In this way, it’s less hardcoded and inside the definition of the Items. So, if you move an item or you insert a new one in the middle, the name -> index mapping is automatically updated without need to touch anything.

Alright, maybe Package is not for me though, considering the above,
and that you mention it needs a DelegateModel, which I don't think I
have any use for (the app is using a StackView as the central
navigation).

Elvis

>
> Ciao,
> Gianluca.
>