2016-03-30 17:22 GMT+02:00 Elvis Stansvik <elvst...@gmail.com>:
> 2016-03-30 16:55 GMT+02:00 Jérôme Godbout <jer...@bodycad.com>:
>
>> You may want to have them declared as list of object with the key as a
>> property of each entry, and build the map based on the list content.
>>
>> ex:
>>
>> *// May have to change the list type here*
>> *property list<Screen> myScreens:*
>> *[*
>> * WelcomeScreen { property string keyName: 'welcome' }*
>> * , OtherScreen { property string keyName: 'other' }*
>> *]*
>>
>> *property var myScreenMap: listToMapByProperty(myScreens, 'keyName')*
>>
>> *// This can be put into pargma library .js*
>> *function listToMapByProperty(list, mapKey)*
>> *{*
>> * var rv = {};*
>> * for(var i = 0; i < list.length; ++i)*
>> * {*
>> * rv[list[i][mapKey]] = list[i];*
>> * }*
>> * return rv;*
>> *}*
>>
>> This should be reusable and allow for easy declaration of Items/Objects.
>> Just need the same property to be declared inside each one. You can also
>> iterate on the list.
>>
>> Here's the result of this code with QtObject, but the idea is the same:
>> *Item*
>> *{*
>> * property list<QtObject> myScreens:*
>> * [*
>> * QtObject { property string keyName: 'welcome' }*
>> * , QtObject { property string keyName: 'other' }*
>> * ]*
>>
>> * property var myScreenMap: listToMapByProperty(myScreens, 'keyName')*
>>
>> * // This can be put into pargma library .js*
>> * function listToMapByProperty(list, mapKey)*
>> * {*
>> * var rv = {};*
>> * for(var i = 0; i < list.length; ++i)*
>> * {*
>> * rv[list[i][mapKey]] = list[i];*
>> * }*
>> * return rv;*
>> * }*
>> *}*
>> resulting into those properties into the item:
>> [image: Inline image 1]
>>
>>
> Thanks a lot, I like this approach very much!
>
Btw, do you think it's a bad idea to use the objectName property for this
purpose, instead of a custom keyName property like you did?
Elvis
>
> Elvis
>
>
>> On Wed, Mar 30, 2016 at 5:19 AM, Elvis Stansvik <elvst...@gmail.com>
>> wrote:
>>
>>> 2016-03-30 11:08 GMT+02:00 Gianluca <gmax...@gmail.com>:
>>> >
>>> > Il giorno 30/mar/2016, alle ore 09:46, Elvis Stansvik <
>>> elvst...@gmail.com> ha scritto:
>>> >
>>> >> Hi Gianluca,
>>> >>
>>> >> 2016-03-30 10:16 GMT+02:00 Gianluca <gmax...@gmail.com>:
>>> >>>
>>> >>> Il giorno 30/mar/2016, alle ore 07:43, Elvis Stansvik <
>>> elvst...@gmail.com>
>>> >>> ha scritto:
>>> >>>
>>> >>> Den 30 mar 2016 8:36 fm skrev "Elvis Stansvik" <elvst...@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.
>>> >
>>> _______________________________________________
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>
>>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
