[email protected] wrote: > 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. "only have to drive the GUI"? There may be our mileage variation in a nutshell, and the mileage depends on the application, not us. "only the GUI" presumes the UI is a simple thing, ignoring what I have said: my application requires a much more lively GUI than most people imagine when they start defining "the one right way" to handle model vs. view. I'll have to end with a teaser until I have time later to respond more fully by actually describing the application, but another thing I said already was that I think the common wisdom about "natural decomposition of layers" does not hold up if one is doing interesting enough things with a GUI application: they in fact are tightly intertwined, even tho in the end we do have view instances for model instances. Then the right mental model is not two layers, one with views that can see each other and one with model instances that can see each other, rather view instances that can each see their model instance. model-view, yes. layers, no. Later I will expand on this. Final note: "now that we have qooxdoo"? Oh, my. No, it is "now that qooxdoo let's us create beautiful, rich web applications". And once one is truly doing that and not just putting up Web 1.0 static pages, as I said, the isolation of model from view underpinning most of the arguments below starts to break down. OK, one more "final" note: not so fast with "except enriching its syntax". Apologies again for being a tease, but I am motivated to expand the qooxlisp wiki page to offer examples of how qooxlisp (via the power of Common Lisp) manages to hide boilerplate without sacrificing needed access to all of qooxdoo's capabilities. If anyone can show me the same thing done with javascript, qooxdoo will soon get a nice contrib. :) And indeed Common Lisp programmers forced to use other languages are often able to come up with powerful approaches that any expert in those languages could have created had they had the motivation that comes from always having such things at hand and suddenly being asked to do without. I'll add as much as seems appropriate to the qooxlisp page and let y'all know here when I do. cheers, ken > > 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 > -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
