Real GUI's or bust

Post #37,212 by tablizer 5/2/02 12:55:09 PM Reply	Real GUI's or bust (* The VS.NET IDE is VB like in that you double-click on form elements and define event handlers and all that rot. ) Yes, but the result is still CGI-like, and not classic GUI. I started reading up on it, and there still seems to be a lot of "e-brochure" artifics in the .NET stuff. What do you mean by "all that rot"? Those are what makes GUI's powerful and relatively simple. An event can change anything anywhere in the app display without worrying about recreating state or sending a complete new copy or what-not. The point is that I don't see any reason why one could not* design an app in the traditional VB/Delphi/PB way, and then have it run in a GUI browser over HTTP without downloading new Turing-complete programming code. (I realize that certain features may not work as well as under c/s, but the majority of what is needed will.) The .NET stuff does not seem like the magic solution. It simply gives more legs to the HTML browser paradigm, but the paradigm itself is the fault that must be replaced. CRC should never have to leave Delphi (a future version) to have a thin-client GUI solution over HTTP. ________________ oop.ismad.com
Post #37,227 by altmann 5/2/02 2:40:00 PM Reply	I realize... I realize that it doesn't go as far as what you propose would be the ideal solution. I was just pointing out that there are attempts to do what you mention near the end of your previous post; put an more traditional event driven API and IDE on the back end of the "typical CGI-like "submit" approach". There are other similar frameworks for Java and mod_perl as well. s/rot/stuff/ -- Chris Altmann
Post #37,279 by tablizer 5/2/02 8:51:28 PM Reply	question, and Master Image (* There are other similar frameworks for Java and mod_perl as well. ) Do you mean similar to .NET, or to my "ideal" solution? The general solution, I have come to tenatively conclude, is to maintain the "master image" (MI) of the interface (widgets, forms, widget content, etc.) on the server. You don't write to the client directly, but to the MI, and then echo the MI to the client as needed. For regular CGI-like flow, you probably have to echo the entire MI to the client each time, since HTML forms were not originally designed to be incrementally altered. However, in a more GUI-friendly approach, you only echo the parts of the MI that changed back to the client. Whether the MI is stored (on server) via XML, objects, linked lists, or tables is a secondary issue. (The advantage of tables over objects is that if you are using a load/unload paradigm, like CGI, then the table stays there between calls, but you would have to recreate the object web {including instances} if using OOP to store the MI. Perhaps Smalltalk can pull it off, but in other OOPL's it is a bit more difficult.) Conceptually, it is a lot like the Cytrix/PC-Anywhere approach where the master image (bitmap) is on the server, except that the "primatives" are GUI widgets specs and not* image pixels. This avoids having to send every cursor movement back and forth between the client and the server. I have been giving these issues a lot of thot lately. ________________ oop.ismad.com
Post #37,290 by altmann 5/2/02 11:07:54 PM Reply	Similar to .NET I was thinking of Struts for Java, though it is not the exact same thing. I'm not sure what I had in mind for mod_perl. -- Chris Altmann
Post #37,362 by tseliot 5/3/02 2:28:33 PM Reply	I find CGI approach wonderfully limiting What do you mean by "all that rot"? Those are what makes GUI's powerful and relatively simple. An event can change anything anywhere in the app display without worrying about recreating state or sending a complete new copy or what-not. Writing web apps means essentially breaking your app into the classic MVC categories. The only thing that should "recreate state" is server-side data; you use CGI for this. Everything else should be either static, or client-side-modified; you use JS+DOM+HTML for this. Now, although I agree with you that JDH is not as "powerful" as a GUI, I find that not to be a significant limitation in my work. Instead, it forces me to think about bandwidth and workflow much more intentionally, separating out those bits which need to be passed from client to server (or vice-versa) and which don't. Therefore, my apps are much cleaner and network-optimized than most GUI apps, both ones I've built and others I have used. Just my 2 cents. --------------------------------- Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #37,368 by ChrisR 5/3/02 3:15:02 PM Reply	Agree for the most part... ...but I sure wish that they'd do a little more work on the input side of things. A combo-box would be nice. (also be nice if the drop down lists were not restricted to a single character lookup). A standard drop-down and popup menu would be nice. Maybe even throw in an input Grid for grins. I find that the later versions of HTML give me a great deal of control over drawing but I get the impression that the input controls have not really changed since V1.0 (other than adding events). It would also be nice if the standards committee hadn't leaned towards deprecating Tables. Although divs and spans can emulate the table technique, it's more involved and time consuming. They give you greater control in that it is tree based, but a lot of times you just want a rectangular two-dimensional array to start dumping stuff. That said, I don't want a bunch of subthreads going back and forth on every page - loading and unloading things on the fly. I'd rather they just standardize the browsers (we're getting much closer) and then maybe enhance the input features a bit.
Post #37,542 by tablizer 5/4/02 11:54:32 PM Reply	Spank-A-Matic ? (* Now, although I agree with you that JDH is not as "powerful" as a GUI, I find that not to be a significant limitation in my work. ) What I find is that managers keep wanting weblications to resemble VB-like GUI apps. JDH-CGI is crappy for that. The same app would be roughly about 1/2 to 1/3 as much code in a C/S GUI tool, be more natural UI-wize, and quicker to develop. I don't like funky paradigms to get in the way of my vision of how I want the interface to be. I want to conduct a symphony with whatever instrument I feel like, within reason. I will have more to post about this soon. ( it forces me to think about bandwidth and workflow much more intentionally, *) You like it because it herds and punishes you? Leave S&M to the hookers. Just don't use bound countrols in C/S tools and filter large search lists/grids at the server stage, not on the client, and you shouldn't have that many bandwidth problems. ________________ oop.ismad.com
Post #37,637 by tseliot 5/6/02 12:42:07 PM Reply	Sorry, I misunderstood. What I find is that managers keep wanting weblications to resemble VB-like GUI apps.... <snip> Just don't use bound countrols in C/S tools and filter large search lists/grids at the server stage, not on the client, and you shouldn't have that many bandwidth problems. I continue to be under the assumption that bound controls and filtering on the client are the essence of VB-like GUI apps. If this isn't the case for you, then what do "VB-like GUI apps" entail that's different from web apps? Comboboxes? --------------------------------- Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #37,865 by tablizer 5/7/02 8:22:27 PM Reply	The pudding is not even in alpha I continue to be under the assumption that bound controls and filtering on the client are the essence of VB-like GUI apps. If this isn't the case for you, then what do "VB-like GUI apps" entail that's different from web apps? Comboboxes? You can change just about anything anywhere on any screen at any time (within the app). If web apps are (or can be) so similar to C/S GUI apps, then how come there are no VB/Delphi/PB-like IDE's for developing them? (The closest thing I know of is the Oracle Forms using it's Java-applet-based "GUI Browser". But Oracle Forms stinks to high heck. It has a certain "personality" that you have to negotiate with. It does not easily allow "changing anything anywhere on any screen at any time" and forces outdated Windows-3x-like conventions on you. If their GUI Browser was only an open standard or OSS, then it might go further.) ________________ oop.ismad.com

Welcome to IWETHEY!