On Thu, May 27, 2010 at 12:22 PM, thron7 <[email protected]> wrote: > Kenny, > > Thinking about it, I would be interested to know how you handle > dependencies between qooxdoo classes in qooxlisp. > > Do you generate the initial GUI from the Lisp code using the Generator, > or do deploy your own dependency tracking and class packaging?
> > Then, with the user interacting with the GUI, you said something like > you would be sending JS strings from the server and eval them on the > client. Do those strings introduce new dependencies, e.g. use so far > unused qooxdoo classes, or do they just manipulate what's already there? > If they introduce new dependencies, would those JS strings themselves > contain the additonal class code? Or do they expect that all necessary > qooxdoo classes be already at the client? > Pretty simple: the app developer has to throw a mention of any "built-in" qooxdoo class they want to use into Application.js. By the same token, any new class they want to use should be authored the usual way, by adding a .js file and doing the generate step. That might sound like it would lead to a lot of JS authoring, but one of the surprising benefits of Cells is that, because any given instance of a class can have its own rule to produce a slot value, there is much less need to subclass. In effect, we get a lot more re-use out of OO, which was the Grail back in the day. Also, because the Lisp programmer is working with CLOS (Lisp OO) instances on the server-side they can do as much sub-classing as they like there. So qooxdoo truly is just the view layer, including handling GUI events of course, but not the application layer, including not even the widget linkage. Here's an example from the demo app: I wanted to disable the Search button if the text input for the search string was blank. So I had various editing events piped back to the server, which returned JS code to enable/disable the search button as needed. That may seem like a long way to go to do what could easily be done on the client, but as long as performance keeps up I like just sitting in my application (in whatever language it might be) and forgetting the client is on the other side of http. If performance is a problem, I will look at using the qooxdoo databinding mechanism to achieve the same end, but strive to do so by programming qooxdoo from the server/Lisp application. ie, I will try not to have to subclass or end up with application-specific code in the static JS. I have done this sort of thing with Tcl/Tk, by the way, which someone ported to GTk. It has gone well in the past, tho now I am going across HTTP instead of a C interface so I'll have my eye open for performance issues, but I suspect they will all roll over for me with sufficient clever hacking. The big win is just sitting in a big language with ready access to server data and almost forgetting HTTP and even qooxdoo exists. About that last: no, we are still programming qooxdoo, and qooxdoo documentation will be qooxlisp documentation, but the design goal is to minimize what the application developer must specify by having qooxlisp intelligently fill in the needed boilerplate to make things work. kt ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
