Hi, We used to use a similar mechanism to the one you've implemented, but unfortunately it doesn't work in more complex cases - specifically any case where JavaScript itself changes the scope chain (ie. function calls).
I've added some more cases to the qdeclarativeecmascript::scope autotest in the qtquick2 branch which demonstrate the problem. Cheers, Aaron On 20/04/2011, at 2:19 AM, ext Caio Marcelo de Oliveira Filho wrote: > Hello, > > As part of the research to use v8 as the backend of QtScript, we are > doing some investigation on QML. > > One complication is that current implementation of QML relies on the > javascript scope chain to extract the current evaluation context, this > is done by using QScriptDeclarativeClass::scopeChainValue(). It is a > complication because currently V8 doesn't give us many tools to > navigate the scope chain in a way to implement scopeChainValue(). > > After giving some thought and reading of the QML code, it seems to me > that in many situations, we can know before-hand what the declarative > context is, and provide this information directly in the > QDeclarativeEnginePrivate. > > The attached patch tries to do that, I've focused first on > tst_qdeclarativeecmascript and QDeclarativeObjectScriptClass > (queryProperty and setProperty used scopeChainValue). The current > patch passes all tests except for one (libraryScriptAssert), that I'm > still investigation why. Any insight would be helpful. > > QML developers, does this kind of change make sense for you? Any tips > about QML internals that I should be aware of? > > > Cheers, > > -- > Caio Marcelo de Oliveira Filho > OpenBossa - INdT > <0001-DRAFT-Avoid-explicitly-looking-at-the-scope-for-decl.patch>_______________________________________________ > Qt-qml mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-qml _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
