Oop Has Ruined Gui Standards

Yeah, I know, this is an "aggressive" and ranty title. Let's just go with it and maybe tame it in the future.

• No, let's not. Don't create pages with flamebait titles. Please find a better title, create a new page, and delete this page.

• Fair enough. How about a question: "Has Oop Ruined Gui Standards[?]".

• [To warrant such a title (or even the one currently on this page), I think you'd have to convincingly show that OO is directly responsible for the limitations in current Web-based UIs. As argued below, that connection has not been well made.]

• It is not appropriate to complain about it up here. It's too early for a summary anyhow. Please don't copy Lars' style; it just leads to endless bickering over whose more evil.

• [Huh?]

There is a huge need for a standardized cross-language GUI engine/interface that is http-friendly. Even though the techniques of GUI's themselves matured to near pinnacle more or less around 1994, we still don't have a decent cross-language standard after almost 15 years.

I believe that OOP carries the main fault for this. Cross language OOP API's are notoriously difficult and messy. Nobody has figured out how to do it right. Thus, instead they reinvent GUI engines for each and every language just about.

I believe the solution would be to use a more declarative attribute-based approach with procedural events, not unlike DBMS stored procedures (but perhaps more dynamic).

The closest we have is JS+DOM, which is messy and still language-specific more or less.

Let the counter-rants begin...

--top

Any Gui Standard is inherently a Language plus a Communications Protocol. I agree we could use a better one than HTML+JS+DOM+AJAX... something designed from the start both for more efficient latency, component caching, and streaming throughput would be very nice. (And such optimization, built into the language or protocol, IS necessary if we are to make such a standard acceptable to a broad enough audience for it to be adopted.)

But I don't see how "OOP carries the main fault for this". The real problem seems to be that "nobody has figured out how to do it right" in a far more general sense, which is why people feel obligated to reinvent it with slight variations.

Yeah, we seem to be stuck to the incremental improvements on the Xerox/Parkplace-MVC style. Time for a revolution perhaps. Time to stir the pot of complacency. Maybe non-XPMVC OOP is also a way out, or at least a big step up even if we stay with OOP engines. --top

I suppose it's attempted to be a joke, but, what is XPMVC OOP? Name me one GUI environment other than Smalltalk that actually uses it? I cannot think of even a single example. Every GUI toolkit made since the Apple Macintosh has most emphatically not used the MVC framework, and attempts to shoehorn MVC on top of a non-MVC GUI architecture results in an ImpedanceMismatch that manifests itself as framework complexity. I particularly enjoy the whole "web-MVC framework" BullShido?. MVC requires nothing less than immediate-mode graphical interaction at its core -- under no circumstances does web-based "request/reply" technology permit this; thus, MVC is utterly impossible with web-based applications. DocumentView makes a bit more sense (where the view and the controller are unified into a single View object) in this environment, if and only if you consider AJAX functionality, but even DocumentView is a molestation of the original MVC concept.

Nonetheless, divesting the software responsible for maintaining a visual representation of something from also maintaining said something's state can only be considered utter common sense. Whether you use OOP or not is irrelevant here -- factor, factor, and factor again.

• In some cases it can result in duplication (OnceAndOnlyOnce violation). See topic SeparateDomainFromPresentation. Why have a toggle switch that stores a value and also mirror it in a variable or non-gui object (unless needed for heavy reference or snap-shotting state.)? --top
  • I'm afraid your ignorance of Xerox-style MVC is showing here. Views do not store duplicate state. The view strictly queries its model for its state, then renders to the display accordingly. Neither additional action nor additional state is required or even desired. Once a view has completed its rendering tasks, it is free (indeed, expected) to discard completely any knowledge it has of the model's state. (For this reason, real MVC very much qualifies as an ImmediateModeGui.) That being said, MVC is, in the strictest sense, a violation of TellDontAsk (since views are expected to ask a model for its state). This might explain the deprecation of MVC in favor of Morphic in SqueakSmalltalk, for example. In Morphic, individual controls do maintain their own state, and programs are expected to query their UI objects for their current state, at least, so far as I can tell. This is also analogous to more commonplace UIs, such as Windows and MacOS. --AnonymousDonor

  • I was mostly referring to the "divesting" comment, regardless of whether that's part of MVC or not. (Thus, your "ignorant" comment is unwarranted.) --top

• [Top, you might find it helpful to recognise that MVC is conceptually relevant to your favourite domain -- business applications. In a rough sense, the model is your database, the user-interface is the view, and the glue between these is the controller. While typical implementations rarely leverage the true value of MVC -- being able to replace any of the three components with different implementations that employ the same interfaces -- you can probably see how there is no violation of OnceAndOnlyOnce. The toggle switch on the screen (the view) is merely reflecting a boolean value in a table in the database (the model).]

• But isn't that true of just about any GUI system? I don't see that as special to MVC, rather its the app requirements more or less. Or, are you talking about "bound controls"? --top

• [I was using it as an illustration of what MVC is, as it appeared you were deprecating MVC in general. At the highest level you could consider most UIs in database-driven business applications to apply, but it's certainly not universal. Using the display widgets to maintain state, and serializing & saving them in order to implement persistence would be a counter-example.]

• I'm not sure whether serializing it or saving it to the DB when "Save" or "Submit" button is pressed makes any difference from an MVC standpoint. May I request specific side-by-side examples of what you are imagining? There seems to be a communications gap here. Almost every CrudScreen app I've worked on does it more or less the same way: copy values from DB (or "source") to screen, user makes changes, presses "Save", and if they pass validation the changes are written back to the original source, regardless of the source (file or DB). Some OOP-ish techniques may write it to a holding record of some kind before writing it out to the DB. Is this what you mean? I often use an associative array to store the column values before putting the row(s) back into the DB, which is not much different. --top

• [I think this thread is wandering into far more detail than I'd intended, and is perhaps losing the clarity I'd hoped to achieve with what was essentially an analogy. Anyway, the intent of MVC is that the complexity of data representation (i.e., the model) is hidden behind an abstract interface, and the presentation layer (the view) interacts only with that interface. Thus, the implementation details of the model are hidden from the view, and the implementation details of the view are hidden from the model. (For simplicity's sake, I shall avoid discussing the Controller at this level.) As a trivial example, imagine that we wish to display a listbox. In order to display a meaningful listbox, we need to maintain a collection of items that will appear in the listbox. One approach would be to wire a linked list into the listbox itself. Aside from being unduly complex, this will only work well until we need to replace the linked list with an array, or a database table, or a queue, or some other data structure. While we could simply copy data from our array, table, or whatever into the listbox (or more accurately, its linked list), there may be numerous reasons not to do so -- e.g., limited memory, we want a "live" display, performance issues, the fact that the "collection" of items is infinite, and so on. So, we are forced to re-engineer our listbox, because it is tied to one specific data representation. Furthermore, we'll have to re-write it for every possible data representation. That means it's not very reusable. It makes sense, therefore, to make our listbox universal -- or at least as universal as is reasonable. If we examine the listbox's internal workings, we'll soon recognise that in order to work, it only needs to get the number of elements in some collection, obtain the nth element, and obtain a displayable representation of a given element -- regardless of what data representation we use. These fundamental operations -- say getSize(), get(i), and getDisplayableFormat(element) -- thus constitute a list model interface. We can now implement a listbox (i.e., a particular view) on anything (i.e., any model) that provides these three basic operations. And, it's easy to see that these basic operations can be trivially implemented on most data structures. Furthermore, we can use the same model to implement other views, such as drop-down comboboxes. Thus, we can easily switch views and models, and even support multiple views on the same model simultaneously. When we switch (or add) views, we needn't worry about the internal workings of the model. When we switch models, we needn't worry about the internal workings of the view(s). That is the value of MVC. (To get it straight from the horse's mouth, so to speak, see http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html)]

• Though I'm no expert on MVC, I believe [Mr. E Brackets] was referring just as much to the content of what is being saved as part of the counter-example. Maintaining domain state as part of the View (the widgets) essentially makes the Model equal to the View, which prevents you from replacing one or the other. Making the View equal to the Controller (the widgets) unites another two components. So, essentially, the example of "Using the display widgets to maintain state and serializing them for persistence" is the complete antitheses of MVC, and is relatively a BigBallOfMud - everything glommed together and ExtremelyInterstrangled offering no ability to refactor or change out (or even distinguish) any one 'component' for any other - no dividing M from V from C. Top's focus on just the issue of 'data' serialization doesn't quite seem to capture the relevance of this example. Am I wrong, [Mr. E Brackets]?

• [You are correct.]

• The goal should be to standardized the GUI engine, not make it easier to swap for a different GUI engine. If an app developer wants to put a layer in between the GUI engine and his/her app to make swapping out the GUI engine easier, that's fine, but is a different issue than what the GUI standard should look like. A GUI engine should not have to facilitate its own replacement by a competitor, at least not as a primary focus. Should the HTML standard concern itself with making it easier to replace an HTML form with a Swing one? (SeparateDomainFromPresentation describes why I feel planning for future GUI swapping is usually not economical.) --top

• [MVC is generally not about swapping whole UIs (though it can be), but about being able to swap views and models on a more fine-grained level, such as being able to swap a listbox for a combobox, or being able to use our listbox or combobox on an array, then on a list, then a queue, set, stack, database table, file, etc., with relatively little effort.]

• If you standardize on a GUI engine, then replacement GUI engines will conform to said former GUI engine's API specifications. Likewise, if you build your system to enable swappable GUI engines, they'll ... conform to a standard, consistent API. In the end, they're precisely the same thing. How many intervening layers exist is utterly irrelevant. As long as the applications sees a consistent set of API entry points that behave consistently as far as it is concerned. it's all the same. No GUI engine I'm aware of facilitates its own replacement. However, standardized APIs facilitate this (indeed, interfaces exists precisely for this purpose -- it's called "modularity," and is a key feature of ProceduralProgramming, which I believe you espouse heavily). Hence, HTML couldn't give a rat's @$$ about whether the form it describes is implemented via Win32 GDI, GTK+, or Swing. Thus, HTML, really, is an interface to some generic GUI infrastructure. So is a model/view relationship. (Also, there is one reason why you'd want to support replacement view interfaces -- the blind. Just you try and implement a screen reader program for a drop-down widget that includes its own list of sub-items. It can't be done, at least not without serious hackery on the part of the implementer. Good luck surviving a GUI upgrade too. With MVC, this becomes a trivial affair. So, . . ., are you going to hammer on the blind, and how we shouldn't support them in your follow-up retort? --AnonymousDonor
  • I don't believe effort involved, and "how many intervening layers exist" to be "utterly irrelevant". But your HTML screen-reader example is a good one: one reason to change 'views' is indeed because people have different interfaces through which to view them. Though a 'view' of the model is in MVC, I think, intended more to correspond to what is essentially a particular 'query' upon it. I.e. MVC has much in common with CRUD screens with updateable views, whereas the language/protocol you utilize to communicate the CRUD screen itself might be designed to support (with little effort) multiple GUI engines. The display and the domain model of what is being viewed and displayed can be considered two independent (as in independently evolving) systems the moment a 'standardized' display/interface language (like HTML) gets involved.

  • [The 'view' in MVC is most emphatically not intended to "correspond to what is essentially a particular 'query' upon it." Do not confuse the 'view' in MVC with 'views' in SQL or the RelationalModel. The 'view' in MVC is about how the presentation is structured, not what data it presents. That is the role of the model (e.g., one might 'query' one model to obtain a new model) and/or the controller. Please see my explanation, above.]

  • You think so? I've seen it called elsewhere about MVC that a gauge on an expression (i.e. a 'query') over model components is part of the 'View' of the model, but you're the expert and both my recollection and source are iffy. I just write GUIs and databases and languages... and never bothered conforming to or learning (or understanding) MVC in particular.

  • [I would question your source. Such conflation of model and view strikes me as confused; like many simple concepts, MVC seems to acquire many (some highly questionable) definitions and misunderstandings. That said, I would not be surprised to find some specific instances where the notion of a 'query' is appropriately located in the View, but I wouldn't consider these a general case.]

• May I ask for clarification on "HTML, really, is an interface to some generic GUI infrastructure."? Regarding the blind issue, one may have to use a limited set of widgets or conventions to achieve practical auto-substitution. It is somewhat analogous to not relying on color in case somebody uses a black-and-white printer, or is colorblind. Some things are just not auto-translatable without making sacrifices. --Top

Of course, there are plenty of other methods of organizing code in a GUI environment. However, blaming MVC for faults that are unequivocally the fault of a proven non-MVC architecture seems shallow and unethical to me. --Samuel A. Falvo II

JavaSwing is allegedly influenced by MVC. Whether its "true" MVC or not is probably a definitional issue.

Because MVC has definitional issues, let's not over-focus on it, but rather traits of OO GUI kits in general regardless of whether they are defined under or tied to MVC. (Related: WhatsaControllerAnyway)

--top

---

AugustZeroEight