CODEWITHSUNDEEP
configurationbuild-processqooxdoo
kennytilton
kennytilton

Reputation: 1064

How configure the qooxdoo generator to include a dynamically referenced class?

First, some context: I drive qooxdoo from other languages such as Lisp and ClojureScript, and I dynamically generate code to reference individual classes.

This normally fails because the qooxdoo generator looks through the static source to see which classes to include.

In the past I have just whomped explicit mentions of classes into Application.js. This works great, but recently I started to grok the config.json syntax and thought it would be nice to take a less kludgy approach.

I managed to add code like this to the "source-build" job and that build then worked:

"include" : ["qx.ui.mobile.page.Manager"]

But I use many classes in an app, so adding that to each job would be error-prone and still ugly.

I tried adding the "include" to the "mobile-common" job which the other jobs extend but to my surprise that did not work. Hmm.. could there be a bug in the job "extend" logic?

I could just add "include" : ["qx.ui.mobile.*"] to all the jobs but that is still ugly and excessive (and I would have still to pull in multiple other classes in each job).

Looking back at all this, it seems there would be no problem if the job "extends" mechanism successfully picked up the "include" option. I just ran the generator with the verbose option -v and can confirm the page manager class is not included if I add the "include" to mobile-common, but it is if I do so on the specific job.

Am I missing something?

Upvotes: 0

Views: 113

Answers (1)

ThomasH
ThomasH

Reputation: 23496

Kenny,

you're quite right using the "mobile-common" job, and it is really strange that it doesn't work. As I don't know your exact config.json file I can only provide some guesses here:

  • The default "mobile-common" job provided with the mobile skeleton already contains an "include" key. You did not by any chance add a second one to the job?!
  • Are you using the mobile config.json directly, or did you create another config file and are including the one that contains the default "mobile-common"? If you use job shadowing (i.e. define "mobile-common" in one config file but also in another which is included by the first), this will influence the content of the resulting job definition (maybe in an unexpected way).
  • The default "mobile-common" job has (for whatever reason) a = in front of the include key, to protect from overriding. You might want to remove that and see what happens.
  • If all fails you can still create your own includer job (like "my-includes"), add an "include" key to it, and then add this job to the "extend" list of the relevant source* and build* jobs. Make sure to add it before the mobile-common entry. This way you can at least maintain your additional include patterns in a single place.

Upvotes: 4

Related Questions