>> What does that mean? Normal qooxdoo app loading, or do you use parts, or
>> what?
>
> Normal qooxdoo application loading. The start-up ends up with an XHR
> request "begin". The server responds with a ton of JS that gets evaled
> and builds the first "page". All events get XHRed back to the server,
> each returning more JS to morph the DOM.
This begs the question how the server knows what to return. Does it
implement its own dependency tracking? How does it relate to what the
'generate.py build' job spits out?
>>> I have it working to use qx.theme.Modern by first including a simple
>>> reference to the class
>>
>> To which class, qx.theme.Modern?!
>
> Yes. I am setting the theme dynamically.
But the tag line, since a couple of qooxdoo releases, is "themes cannot
be changed dynamically". So, I don't know how it is implemented but my
best understanding is that you just have to set the setting "qx.theme"
to the meta theme class, and that's it. I'm not sure the setTheme() call
does anything effectful, which probably didn't matter for
qx.theme.Modern as it is the default qx.theme anyway. - Try commenting
out the setTheme call and see if it still works.
>
>>
>>> in Application.js, which I have end with an XHR
>>> on a URL "/begin"
>>
>> Is this significant for the problem?
>
> Do you love requests for information that hold back what the asker
> thinks/hopes does not matter? Not me!
Just trying to figure it out...
>> The interesting question is, is the Modern theme still drawn in as well?
>
> Not sure what you mean. Nothing happens, I get the qx.Class error.
Sure, in the running app. But what about the generated .js files?!
>> Do you want to list all classes you use in your Application.js<rofl>?!
>
> teamalgebra.com
>
>> That's a funny way to code.
>
> This is a funny way to offer technical help.
Now, now, you and your teamalgebra have all of my sympathy. But there
are really, um, more canonical ways to inject dependencies than listing
class names in the app code. - Still I don't get how this all fits
together, as I don't have a picture how the generate.py build output and
your server delivering code to the client relate to each other. If you
e.g. were using standard qooxdoo parts I would be able make some
assumptions about their properties and what gets sent from the server when.
> Apparently you did not understand what John McCarthy did back in 1956
> when he realized code should be data.
:-) No, indeed, as I wasn't born at that time ;). (C'mon, Kenny, this
isn't c.l.js).
> teamalgebra.com is a Common Lisp application including an Algebra editor
> and Algebra expert engine running on the server. Somehow the server
> application seamlesly includes a GUI layer that runs on the interweb.
> Still laughing?
Never laughed about that. Some other projects use qooxdoo as the pure
rendering layer for a server-driven app. But that raises a lot of
issues, as that of dependency tracking on the server, I'm not familiar
with, and can be done in various different ways.
> Yes, I did that. That is what I was asking. I did both the bar
> darktheme.DarkTheme in Application.js and set the QXTHEME JSON value
> (not sure why you say macro)
That's just lingo, to emphasis their use in the config system (think of
m4 rather than Lisp :).
> to "darktheme.Theme".
Right, so the points I wanted to get at were:
- are the darktheme classes included in the build? - you can check that
by looking at the generated .js files (just grep for their class names);
what you write slightly suggests they're in.
- are the theme classes delivered to the client? - I have no idea, as I
don't know how your server-side code packager does and how it assembles
the code packages it sends back to the client; in the worst case, you
have to inspect the files *in the browser* in some debugging console, to
check if the theme classes arrive there.
- in the browser console, check the "qx.theme" setting
qx.core.Setting.get("qx.theme")
and its availability
qx.Theme.getByName("darktheme.DarkTheme")
This is all focused on theme handling, so actually doesn't answer the
question why qx.Class would be undefined. Again, you have to inspect the
downloaded .js files. I presume your initial Application.js is not run,
so the issue must be in the very first package. How is this package
created? What is actually in it? Which qooxdoo classes?
T.
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
