On Thu, May 27, 2010 at 3:24 PM, thron7 <[email protected]> wrote: >> 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. > > Ok, so if I got that right, as far as the GUI is concerned you create a > usual (however thin) qooxdoo application upfront that will contain all JS > classes that will possibly be used during run time. This application is > send down to the client on first request. On subsequent requests, the > server sends JS code strings that manipulate existing objects or > instantiate new objects from the already loaded classes. - Did I get that > right?!
Yes. > >> 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. > > Sorry, but I'm unfamiliar with Cells. I read your announcement back then, > but never got around to actually grok it. But nevermind... It works a lot like databinding, I think. > >> 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. > > I don't want to bother you with "inferior" Lisps, but that reminds of Lutz > Mueller's "newlisp" (newlisp.org) who is driving Java GUI's from Lisp (I > believe he uses sockets). There is another Lisp+Tcl/Tk package that drives Tcl/Tk over sockets. > >> 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. > > So are you generating qooxdoo code/templates from the application's Lisp > code? I am not familiar with qooxdoo templates, and did not spot anything in the doc after a quick scan. Is there a link you can provide? kt ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
