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.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
