Matthew Gregory schrieb: > Have you tried looking at creating an inline application rather than a > standalone. Not sure what you are trying to achieve but sounds like you > want an inline application. > That's the way to go. The standard GUI application uses the "body" element for the root widget and takes full control over the page. The root widget will assume that it "owns" all child elements of the body element and will remove all unknown element.
Best Fabian > dmbaggett wrote: > >> I'm very impressed with QooxDoo, both the surface UIs it generates and the >> code underneath the hood. Thanks for all the hard work it has taken to get >> it to this point. It's really impressive. >> >> I have a challenge, though. I've loaded my RIA QooxDoo script in a frame, >> and I've set my Application's main method to simply return without doing >> anything. It does not call its superclass constructor, for example. This >> means that although the QooxDoo script gets loaded when my page loads, the >> browser window doesn't get taken over by QooxDoo when the page load >> completes. Things look like a simple HTML page at this point, even though >> the QooxDoo script has been run. Later, after some other setup stuff, I call >> the main method's superclass, constructor causing the QooxDoo application to >> start up and take over the page. >> >> My problem is that when the application starts, it causes the page to be >> refreshed, and objects embedded in the page, like applets, get restarted. (I >> need to use a helper applet to do various things that I don't want to -- or >> can't -- do in JavaScript.) The applet reload causes lots of problems, >> because I lose all my applet state in the process. >> >> I've looked through the QooxDoo code quite a bit and generally find it >> pretty easy to follow. But the startup sequence eludes me: I don't know >> where to start looking in the source to find out what's going on. So I have >> a few questions: >> >> How can I prevent QooxDoo from reloading the page -- or whatever it's doing >> -- when it starts? Can I keep it in a frame in order to limit its domain of >> control? (Say I want to have two frames, one with QooxDoo and the other with >> the applet, for example.) >> >> More generally, could one of the QooxDoo gods tell me what exactly QooxDoo >> does to the DOM tree when it starts up, and what control I might have over >> this process? E.g., my embedded objects don't seem to go away, but QooxDoo >> seems to be doing something that's tweaking them. >> >> One final question: in experimenting with alternative ways to get content >> from the web server, I tried using an AJAX-like method to retrieve the >> QooxDoo script from the server and then eval-ing it. That didn't seem to >> work: nothing happened. Is there something about QooxDoo scripts that would >> make them not work via eval? (I do realize that eval-ing a 1MB JavaScript >> file might not be a good idea for other reasons.) >> >> Thanks for any help! >> >> Dave Baggett >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > -- Fabian Jakobs JavaScript Framework Developer 1&1 Internet AG - Web Technologies Ernst-Frey-Straße 9 · DE-76135 Karlsruhe Telefon: +49 721 91374-6784 [email protected] Amtsgericht Montabaur / HRB 6484 Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael Scheeren ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
