On Wed, Nov 23, 2011 at 7:31 AM, <[email protected]> wrote:
> João Abecasis Wrote:
>>On Nov 23, 2011, at 2:54 AM, Alan Alpert wrote:
>>But it goes back to my assumption about there being a use case for storing
>>(yes, and loading) application-specific configuration data. Do we agree on
>>this?
>
> Definitely! I'm just confused about all the different approaches and how they
> relate. There's no need for a Settings API like this if the offline storage
> API is good enough (and it is not, and never will be so long as we try to
> copy the HTML standards). Similar with JsonDb. So we'll end up with someone
> wanting to store application data and they'll pick whichever they find in the
> docs first. Which would be really bad if the Settings API ends up gorgeous
> and they found offline storage first :( .
I think a Settings API is welcome for simple use cases, basically when
you need to map 1-1 attributes, like user preferences (ex. sound
on/off). It simplifies data synchronization, providing an automagic
way to handle that if using the alias approach.
>>What is the use case for JsonDb, anyway?
>
> Beats me. I should ask them the same challenging questions of why anyone
> would use it when we're designing this great new Settings API ;) .
I would ask the same thing. It would prefer an imperative SQL API, to
do something like below:
SqlDatabase {
id: db
type: SqlDatase.SQLITE
source: Qt.resolvedUrl("app.db")
}
ListView {
model: SqlQueryModel {
id: model
database: db
query: "select id, score, rank from levels where rank > 0 order by rank"
}
}
Br,
Adriano
_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
