[Development] QML and JavaScript extensions

[Alan Alpert]

On Fri, Nov 15, 2013 at 2:17 PM, Kevin Krammer <kevin.krammer at kdab.com> wrote:
> [...]
>> Quoting your latest post:
>> > I can understand that you'd like to have the same script engine evaluate
>> > both types of script, but since the decision was to make an optimized
>> > version for QML, you can either try to shoehorn your code into that
>> > limited engine or use what you already have.
>>
>> The engine that runs QML implements the ECMAScript standard and it must
>> have all the necessary tools for extending JS with C++. Otherwise, it
>> could be used to implement neither QML, the extensions QML already has
>> added to ECMAScript nor ECMAScript itself. The lack of a public API to
>> these features is the only reason I need to do the shoehorning every
>> time the engine is changed.
>
> True. If QJSEngine is defined to be fully ECMA compatible then that is of
> course possible.
> I was primarily working under the impression that while QJSEngine was intended
> to replace QtScriptEngine, the need for V4 made that less likely.

V4VM is intended to be a fully ECMAScript compatible JS engine (I
think it's there already even, for the first release!). The special
needs of QML are either in performance profile, or only in the "QML"
parts of QML/JS. AFAIK, the plan (no more long-term than when we were
using V8 ;) ) is still for QJSEngine to expose a full ECMAScript
compliant JS engine for application scripting, similar to QtScript but
QML integrated and avoiding running a second JS engine.

>> >> Qt is heading to a JavaScript-based future. Widgets are deprecated and
>> >> replaced by QML. In this situation, a good extension interface to the
>> >> JavaScript engine that runs QML is a really important feature.
>> >
>> > I have to disagree with a couple of items here.
>> >
>> > Qt has already had JavaScript based scripting support for ages, so it is
>> > not heading into using it.  As for JS in QML, any sensibly designed
>> > application will avoid doing business logic process in the UI. That was
>> > already not a good idea when using C++, no need to continue bad practise
>> > when the new UI technology hands you a nice way to correct that.
>>
>> In Qt4, widgets were still the main UI technology. Nowadays, widgets are
>> "deprecated". (I'm putting quotes due to the comments to my last post,
>> but it is really not hard to see where the development is heading.)
>> Prior to QML apps, JavaScript has been a tool to provide scripting
>> support for C++ applications, but applications were not based on it.
>> Now, the situation has turned around: JavaScript/QML app, C++
>> extensions. Therefore, I'm sticking to my statement: a good extension
>> interface is an important feature.
>
> We will have to disagree there. I consider the UI to be replacable, as free of
> application logic as possible.
> In that model QML instantiates objects and connects/binds them.
>
> I understand that there is a different approach, basically creating
> applications like webapps. Do all processing in the UI, only use components
> for visualization and platform integration.

It's more complex than that, because the split between UI logic and
application logic can be hard sometimes, especially when the multiple
UIs aren't exposing the exact same functionality. (Obviously they
expose the same core functionality, but maybe the enterprise edition
has more cowbell?)

The intended approach, for a JS/QML app with C++ extensions, is that
the UI and UI logic are in JS/QML, the application logic is still in
C++, but it's exposed through reusable modules. So some stuff that's
on the edge moves from "application" logic to "ui" logic. As an
example, take storing high scores in SameGame. Current model is that
it's application logic (NB, samegame has the app logic in JS) but with
a "HighScores" module encapsulating that logic, it could move out of
the JS files and start using that module from QML directly as passing
the score to the "logic module" is UI logic. The advantage here is
that new UIs can bring in modular secondary functionality easily, like
web highscores or time-decay highscores, without needing to touch the
application logic. Sorry I don't have a very clear example/story here,
as I said we're not up to this point for realistically sized apps ;) .

--
Alan Alpert