Hi. > 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.
Idunno. I like Javascript. It may not be the richest language in the world, but it is built in such a way that you can easily do anything to it in javascript code, except enriching its syntax. Besides, you only have to drive the UI from it. I suppose qooxlisp has to replicate the entire UI state on the server to be able to properly react to events in the UI. Right? Alternatively you can go the ASP.Net way and pass the state along with each request and response. But somehow state has to be available on the server in order the server to be able to react properly to UI requests/events. Therefore, I can't really see the benefit of it. Indeed, you do keep application-specific logic, including UI-related logic, in your preferred language, but IMO there are two significant disadvantages to it, both related to the fat state information corresponding to rich UIs. First, in the case of large number of users, resource consumption grows much faster than in case of an architecture which requires no state or only slim session state on the server, which also doesn't change very often. Second, in case of fat and dynamic session state which is maintained on the server, clustering becomes complicated (due to complicated replication of the state info across cluster members). Alternatively, if instead of maintaining the fat state on the server it is sent along with each request and response (the ASP.Net way), computational effort to serialize/deserialize it becomes significant, especially for a chatty web app, where ever ything is handled on the server. All of these are most likely no issues in case of small numbers of users on an intranet. But each of them easily becomes a bad pain if your application is used concurrently by just a few tens of thousands of users, and it's even worse if your app is accessed over the internet, in which case you have no control over delays, lags, routing speed etc. A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript code, and define a set of JSON-based requests and responses upon which the UI application has to rely. There are several advantages to such an architecture. First, you only have to keep very slim session info on the server. Small session info which almost never changes during a session (a user name, an authentication token, only things like this) allows for much higher scalability. Second, a natural separation of concerns arises between layers. It's very well defined what the server has to do, in fact, each request/response can be handled in isolation. Similarly, the various UI parts can each be handled in isolation, as they each rely on specific data being retrieved/sent, less on data provided by other UI components. This allows for many programmers working in parallel on the various parts, without needing too much synchronization among them. Third, the well-defined set of JSON requests/responses constitute a natural interface for third-party apps which need to interact with your app - one which doesn't expose app internals, and thus protects your app from having its data damaged by external code - such as would be the risk when doing integration at the database level. Fourth, the nice isolation between layers and between components inside a layer allows for improved testability. You can unit test each component in context, without wrapping it in tons of mocks. Essentially, my point is that now th at we have qooxdoo, to use it with state and UI logic managed server-side would be to some extent a pervertion of its purpose. For years before qooxdoo apps were written this way, and web app development was a pain in the ass. I for one don't want to go back to that type of apps, even if this would allow me to code everything in my language of choice. br, flj ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
