[Development] Toolability of mixing QML and JS

Rutledge Shawn Shawn.Rutledge at digia.com
Wed Jun 26 14:26:27 CEST 2013

On 26 Jun 2013, at 12:00 PM, Thomas Hartmann wrote:

>> - Editors: A lot of IDE's out there understand .js files. Writing a parser for only the declarative parts of QML is relatively easy. Writing a parser for .qml files that also understands all of JS, not so easy.
> We provide a QML parser that includes Java Script as open source. Anyone 
> who wants to parse QML is most likely to use this one and even if not he 
> has access to the complete grammar. So this is not really an issue.

I see it as an issue if you had to write that parser.  No wonder it's out of sync with the actual language parser.  The one in declarative should have all the features that you need, with suitable (ideally even public) APIs to access those features, it should be in the declarative module, and there should be autotests to keep it consistent.  So the workflow for tooling should be that you use the declarative parser to get the AST, the tooling has the opportunity to modify the AST whenever the user does something, then you can send it on to the engine for rendering a preview, and you can also regenerate the source code by pretty-printing the AST.  That means the AST must be complete: it must include Javascript (even if they are only unmodifiable blobs) and comments, so that the pretty-printing will generate the same source code with only the changes the user wanted to make.  But for optimization purposes there could be a parameter to the parser to ignore the comments, because tooling needs them whereas the interpreter does not.

More information about the Development mailing list