08-21-2012 05:49 PM
what's the recommended way to structure a Cascades app in respect of QML ?
I want to divide my QML Code into some QML files to get a better re-use of components and also to avoid huge qml files to edit.
I'm using a TabbedPane with some Tabs, so I thinkl it could be a good idea to have separate QML files for each Tab:
and my main.qml contains something like
If the code for my Tabs would be included, I can access all properties inside main.qml,
if I'm putting it outside in an extra qml file, I have to declare some alias properties to access components inside.
there are some other similar scenarios and also if you have a NavigationPane and want to push / pop some screens, pushing them using the path of the qml file is deprecated, you have to attach the Pages etc. to your qml document. Again the question: should I define all attached Pages etc. in my main qml or place the definitions into another qml file and access thru alias properties ?
what do you think ?
what' s the recommended way ?
08-22-2012 01:40 PM
The "QML Documents" page in Qt Assistant seems to state that the purely lexical mechanism (i.e., "include") isn't available.
As you're no doubt aware, more or less late-binding mechanisms can be used, e.g., the "qmlRegisterType" and "import" semantics (cf. the "repeater" example), or the "loader" approach in the sample project of that name.
If RIM dev support has any additional information / clarification on this topic, I (too) would be interested in learning more.
08-22-2012 01:51 PM - edited 08-22-2012 01:54 PM
Take a look at how cascadescookbookqml and weatherguesser organize their qml.
If the application is tiny, sometimes it's easier in one QML.
In general, it's easier to keep one QML per "view" or component.
The files themselves do not need to be stored flat in one directory.
e.g. cascadescookbookqml has a directory assets/Common.
Note that files that need things from Common need to #import "Common"
(You could for example make a directory called "more" and throw Label.qml into this directory. In this case you would have to adjust recipemodel.xml, and the #import in Label.qml to #import "../Common")
And as Transendental points out, dividing QML along logical and structural boundaries means you have the option of doing late binding.
08-23-2012 05:38 AM
thx Transcendental and smacmartin
so my thoughts are already into the right direction.
will divide the qml into one QML per View / Component -
what do you think: will this be a problem:
one data model bound to two Pages, one for Portrait, one for Landscape,
dynamically switched if orientation changes ?
unfortunately at the moment there's no concept like Fragments to solve this 'out-of-the-box'
08-23-2012 08:44 AM
Sure. And yes, they are called DataModel, but in this case think "controller". If you have multiple data models to feed the same data in different ways, the underlying UI-independent data (model, in MVC parlance) would be in yet another place. Of course, that could just be an XML or JSON file, but could also be SQL or code.
08-23-2012 08:59 AM
the concept of DataModels is clear, I asked because I don't know what happens under the hood inside Cascades if data will be displayed per ex. in a List and the same dataModel is connected to portrait- and landscape - Page
then... orientation changed ...switching from portrait to landscape Page (connected to exactly the same data model, but perhaps displaying the data different)
then... orientation switching back ...
only wanted to be sure that I'm not running into memory or performance issues