Hi Walter, welcome on this list :).
> We are currently evaluating RAP and I have been tasked with looking into some > of the details of RAP and qooxdoo. I have a fair degree of experience with > action-based Java web frameworks and JavaScript (and in particular YUI). I'd > like to ask some questions to try to better understand how qooxdoo works (in > particular how it works in RAP-based applications). Apologies if this is not > the appropriate forum for these questions, if these questions seem naieve or > if I have misunderstood anything. > No bother. And we will try to answer your questions to the best of our knowledge. But although we are in good touch with the RAP guys, our knowledge about the RAP internals is second-hand, and you might want to consider asking these questions on the RAP mailing list too. > Firstly, qooxdoo appears to be fairly extensive and well thought out. Thanks :). > From my limited understanding of both RAP and qooxdoo it appears to me that > qooxdoo is a natural choice for a solution like RAP, which leads to my first > question: how many of the features of RAP are really features of qooxdoo? > e.g. I know the RAP team are working on improving themeing support, but will > this simply be implemented by upgrading to qooxdoo 0.8 and providing the > themeing features of qooxdoo? > This is something I can't tell. The cut point between RAP and qooxdoo might vary from feature to feature. I'm not sure about the implementation of the themeing support. > One of the first things I noticed when looking at the qooxdoo manual was the > syntax for accessing static members of a class (i.e. > this.self(arguments).PROPERTY). I don't understand why it is necessary to do > this instead of something like my.package.Class.PROPERTY, in particular I > don't understand the need to pass arguments to self. I'd really appreciate an > explanation of why this syntax is necessary. > qooxdoo has a way of getting at methods and properties of parent classes. "this.self()" is a generic method with every qooxdoo object, to return the class object in which the current method is defined (so you always get the defining class, even if the method is called in a derived class that doesn't overload it). It needs the "arguments" argument simply to do its job. Nothing is actually done with the actual parameters to the current method. It's only about the class hierarchy. "my.package.Class" will work just the same, and is actually the recommended way to do it. There is a related idiom in qooxdoo named "this.base(arguments)". This will actually *call* the corresponding method of the super-class. The "arguments" vector is now used for both, determining the super-class method and actually evaluating the parameters. > I've also noticed that RAP applications appear to use absolute positioning > for every element and define some possibly redundant inline styles (e.g. > border-color and/or border-style when border-width is 0). Is this because of > qooxdoo or a choice made by the RAP developers (the more complex qooxdoo > demos seem to use absolute positioning and inline styles)? > I believe the main reason for this is the fact that in RAP layout is managed on the server, so they use absolute positioning on the client. I'm not sure about the inline styles. > I still haven't quite got my head around the event system in qooxdoo. I > understand it supports Custom Events (i.e. not simply DOM/browser events), > but couldn't find any documentation on this when I briefly looked over the > manual. Where should I look for a better example of how to use these in > qooxdoo? > You can find a general introduction to the event system here: http://qooxdoo.org/documentation/0.8/event_layer_impl (Ok, this might be a bit technical for an introduction). The API doc for the qx.event name space has also some contextual information: http://demo.qooxdoo.org/current/apiviewer/#qx.event On a practical level, all you normally do is creating objects and registring event handlers with the events that are supported by that object (see the API doc for the specific class for supported events). Some of the standard demos might be instructive in this regard, such as: http://demo.qooxdoo.org/current/demobrowser/#event~MouseEvent.html (Hit the "JS Code" button after the demo has been loaded to see the implementation. You may want to look at other samples from the "event" group in the demobrowser). Get back if you feel you still don't get the information you need. > Finally, if we were to adopt RAP we have a number of widgets we have > developed in house based on YUI (and possibly some based on Prototype) that > we would want to adapt for use in RAP. Are there any recommended approaches > for using qooxdoo to wrap widgets written using another framework? > I'm afraid I'm lost on this one. Anybody else?! Thomas ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
