Hi again
There’s a new release which includes support for translations; you don’t have
to do anything to enable it, just rerun the qxcompiler.
If you want to update your .po files with new translation strings, there is an
example of how to do this for the qxt application in
test/update-app-translations-demo.js, but basically after maker.make() has
completed, you just call maker.updateTranslations()
// ...snip...
/*
* Make it
*/
function (cb) {
maker.make(cb);
},
/*
* Translations
*/
function (cb) {
maker.updateTranslations(appLibrary, cb);
}
// ...snip...
BUT:: because this modifies the original *.po files in your source directory,
please take a backup of your files first.
Build Target compression is next :)
John
From: John Spackman <john.spack...@zenesis.com>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Wednesday, 17 February 2016 at 09:08
To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and
100% Javascript API to building applications
Hi Dimitri
No worries, those are the kind of bug reports I like to hear, ones where it’s
not my fault! :D
Actually I’m a little surprised that the generator supports the # compiler
hints still, I thought that had been dropped ages ago; I have yet to add
warnings output for unresolved symbols etc so I’ll include warnings for old
style hints too.
Babel is on by default, so there’s nothing extra you have to do to start using
ES6. In the qxt Application.js there is this:
button1.addListener("execute", () => alert("Hello World!"));
I’ve got some customer work I have to get done this morning but hopefully have
some time put aside this afternoon to finish off translations. It’s not too
big a deal, most of the work is in reading and writing the .po file format so
both the extraction of strings process and the loading of translations will be
included. Hopefully todays release will include build target compression too.
Regards
John
From: Dimitri <mi...@cargosoft.ru>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Tuesday, 16 February 2016 at 21:34
To: <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and
100% Javascript API to building applications
Hi John,
Sorry for all the stir I've raised around resource handling. The problem was in
our code. It turned out that we were still using old-style compiler hints
(#asset, #use, #require etc.) ignored by QxCompiler.
This in fact caused both issues (resources and unmarshalling). With #asset
being ignored, obviously, no resources could be loaded. The second case was a
bit more complex. By some obscure reason (Java habit?), we used the following
construct in IMarshalDelegate implementation:
/**
#require(foo.Bar)
*/
...
getModelClass: function(properties) {
switch(properties) {
case 'foo"bar':
return qx.Class.getByName("foo.Bar");
default:
return null;
}
}
Obviously, foo.Bar wasn't available at runtime, and the data was unmarshalled
to default (generated) class, while foo.Bar was expected. I've eliminated
compiler hints completely and replaced qx.Class.getByName calls with direct
references. Everything works perfectly now! :)
(I don't think old-style syntax is worth being supported in QxCompiler, but in
order to aid oblivious guys like me it would be nice to mention in the docs
that #-hints are not supported and should be replaced with @-hints.)
The only two remaining issues are translation (the app runs with its default
locale and doesn't pick up *.po files) and script size for single-script build.
Load time is much better now, I guess that 10 second delay was caused by
unoptimized resource handling. Yet I didn't try any actual Babel
transformations; as far as I know, it doesn't do anything by default. For those
unfamiliar with Babel, it would be nice if the docs contained some examples of
how to actually enable Babel transformations.
As for build setup, I've come up with the following. The script that drives the
build lives in VCS in the project directory; upon checkout, "npm link async" is
executed, which is a cheap operation that installs a symlink for async module
(previously installed globally). It's the only module that is required by the
driver script; the rest is successfully pulled from QxCompiler directory.
Cheers, and keep going! QxCompiler is definitely the coolest thing that
happened to qooxdoo in last months and maybe years :)
Dimitri
Hi Dimitri
So it sounds like resources with paths have an issue, or maybe libraries with
“.” in the namespace – I’ll have a look this morning but as it’s happening with
UploadMgr then I have a reproducible case I can work on.
I’ve had a look at the stack trace – but I can’t see any clues to what might be
causing it; by marshalling, do you mean the qx.data.marshall.*? That should
not be affected, the only change to code was to allow .defer() to not be called
immediately after the class was defined. I’ve just realised that this means
that dynamically defined classes will not have their defer called, and there’s
a fix in the next commit for that but I don’t think that’s the issue your
coming across.
Re Node 0.12: I think there was another problem with early versions of Node <=
0.12 other than just language – I can’t remember exactly what now but there was
something that didn’t work properly until I upgraded. But you’re right,
QxCompiler could be babelified :) At one point, the Babel plugin part was
written as a proper, standalone babel plugin in ES6 but I had some trouble
getting Webstorm to compile and debug properly so I switched back to native code
Re build server: I’d expect QxCompiler to be installed once, globally and then
used externally to the projects, i.e. your build code could do the project
checkout and then use the API to build each project. The project wouldn’t know
about QxCompiler at all.
This sounds similar to my use case, except my builds are on-the-fly on product
servers rather than as part of release: In my case I have multi homed Tomcat
servers, and each website uses Qooxdoo on the server and client; the server
apps generate html (think ASP/PHP/JSP but with javascript & Qooxdoo running
under Rhino) as well as implement server processes, and there is often more
than one client application per website. Doing a major release requires
deleting and recompiling all applications (and typically the cache also), and
with a minimum of 2 apps (1 server + 1 client) per website that can be quite
expensive. At the moment, making a minor patch to the presentation of the
website (e.g. modifying the html output from my PHP/ASP-like pages) means an
expensive build process too which is pretty tedious.
So what I want is to have QxCompiler sitting as a background process, watching
all these applications and the source files they depend on; when a source file
changes it rebuilds the app instantly (e.g. 250ms per affected application) and
notifies Tomcat to reload the server code if necessary. At the moment,
incremental builds take QxCompiler approx 700ms including the (not
insignificant) overhead of starting up node.
Re requirements: I’ve updated the docs to match
I’m working on QxCompiler again this morning and should have an update for you
by lunchtime
Cheers
John
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end
web transactions and take corrective actions now Troubleshoot faster and
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end
web transactions and take corrective actions now Troubleshoot faster and
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
