Lists in QML, QDeclarativeListProperty

Another big concern is that advised approach requires to implement different classes for integrating javascript/qml/webkit. Till this moment I could (and I did actually) implement just one class proxying some c++ core functionality to
1) javascript extension (using QScriptEngine::newQObject())
2) QML (using QDeclarativeContext::setContextProperty())
3) html pages (usig QWebFrame::addToJavaScriptWindowObject())

(enums require different injecting approach in webkit - each enum value as a property, but it's tolerable, though still not good and should be fixed as to me)

Advised solution with QDeclarativeListProperty forces me to implement and support whole proxy class tree to make c++ core functionality available in qml. Also the qml/script extension are harder to develop/maintain because of using different style api.

To tie the needs to something real: my case is a functionally rich self-service kiosk software that is installed on thousand terminals in Russia and CIS allowing customers to make electronic payment through these machines. The interface is highly customizable and consists of
a) use-case scenarios made as finite-state machine with state handlers in javascript (QStateMachine + QtScript)
b) screens/widges made in qml/html/c++ plugin (QDeclarativeEngine + QWebKit + QPlugin)

All these parts (qml, webkit, qtscript) of the application get the core functionality through classes that wrap core c++ interfaces to expose them as slots/signals and properties. At the moment the wrapping classes implemented just once and work for all cases, and that's just great! This is the result of Qt framework maturity. And it would have required much more efforts to create such an application if the scripting api had been not consistent.
My opinion is that you should keep this consistence of the scripting part of Qt always considering qml/script/webkit needs and api together.

Find attached a small example which demonstrates the use of QDeclarativeListProperty.