Jump to content

KDevelop/QMLJS: Difference between revisions

From KDE Community Wiki
Ochurlaud (talk | contribs)
m 2 revisions imported
Scummos (talk | contribs)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
= JavaScript =
= JavaScript =
== support objects ==
Currently something like "foo.bar.asdf" is not supported properly. We look for each identifier on its own instead of first looking for foo, then inside foo's internal context for bar and so forth. This is especially required for proper use building. But for declarations as well, e.g.:
<syntaxhighlight lang="javascript">
// constructor
function MyObj() {
  // method
  this.foo = function() {};
  // property
  this.asdf = 42;
}
// alternative way to declare method
MyObj.prototype.bar = function() {};
// this is how you'd use it:
var obj = new MyObj;
obj.asdf++;
obj.foo();
obj.bar();
</syntaxhighlight>
See also e.g. this document showing three ways to declare "classes" in JavaScript: http://www.phpied.com/3-ways-to-define-a-javascript-class/


== Documentation ==
== Documentation ==

Latest revision as of 10:22, 15 March 2016

JavaScript

Documentation

For better static analysis we should parse and extract information of JSDoc-formatted comments: http://en.wikipedia.org/wiki/JSDoc

We should eventually write a documentation plugin. Maybe we could generalize the php-docs plugin to be extensible for arbitrary URLs / languages. For JavaScript this seems to be a good page for English developers: https://developer.mozilla.org/en-US/docs/JavaScript/Reference While this is a good one for German developers: http://de.selfhtml.org/javascript/objekte/

Generally, we'll need something similar to PHP's phpfunctions.php file to specify the default JavaScript browser API. It should be extensible by arbitrary files that specify non-browser APIs, e.g. for Kate scripting. Comments could come from JSDoc.

QML

binary plugin support

We should look at how QtCreator/QML figures out what API a plugin provides. We'll also need to be able to setup custom QML import paths probably.

project-specific API

If one works on a project that creates its own QML plugin we should be able to figure that out somehow using the project builder and the C++ language plugin. Then we could deduce the API directly from the C++ DUChain information.

documentation

I hope that we could make use of the QtHelp plugin for default QML types and should add proper support for DoxyQML for additional static analysis opportunities for custom QML types. http://agateau.com/2013/01/14/introducing-doxyqml/