See a tiny example at a little multiplication toy, a slightly bigger one at Revello
MVC is starting to accumulate heterodoxy, including "MVC considered harmful" [2], ...EKB That's an interesting article. It's about an alternative approach called "context-oriented programming". I made a short example on ContexTcl: Playing with Context-oriented Programming.
PYK 2014-05-20: One possibly-useful guideline is that what to display belongs in the model or the controller , and how to display it belongs in the view . This guideline helps keep program logic from creeping into the view .
EKB One way to use the MVC pattern that I apply frequently is to make a core program with programmatic hooks and no user interface elements at all. After making it, I build a command-line program that sources a script that accesses the model. Basically, this means using it as a mini-language, which I think is a particularly Tclish (and Lispish) thing to do. Often the development stops there, because it's all I need, but it doesn't have to. Because it uses the MVC pattern, it would be easy to make a Tk interface that makes use of the core program. There's an example at Mini-language as Model-View-Controller.Lars H: Hmm... As used above, "mini-language" seems almost a synonym of "package" (although perhaps not registered via the package mechanism). Is there some other distinction between the two that you feel is noteworthy but perhaps not immediately obvious, or is it just a matter of terminology? One distinction could be that a package is often set up to support multiple clients (if it keeps state, then the client might need to provide a handle to the particular context to use) whereas a mini-language has a global context shared by all (at least in that interpreter), but that could just as well be irrelevant.EKB Not in terms of the code, but in terms of presentation and use, yes. On one hand I find that if I think about a package as a mini-language then I implement the package and the application somewhat differently. On the other hand, I find that exposing a package as a mini-language (or "domain language") and then presenting it to users that way, without ever mentioning Tcl, leaves them very impressed. It's still good advertising for Tcl/Tk, because later when they ask about it, I say, "Oh, yes, that's quite straightforward in Tcl." This ties into two things that I see in software development discussions: a) the use of domain languages as a strategy (highly recommended in the popular "Pragmatic Programmers" books); b) Lisp as the natural platform for making mini-languages (although not by the Pragmatic Programmers -- they like Ruby). But Tcl is also a natural platform for it. As I was thinking about the mini-language code I've written, I realized that it might be possible to add a (c) to this list, that a mini-language is a natural way to implement MVC that is (IMHO), more transparent and easier to implement than implementing MVC in, say, Java.So, the crass view of saying "yeah, it's just a package, but..." is that it's a way to do some Tcl evangelism using some popular concepts: domain language and MVC. Something like, "TCL can implement MVC via a domain language at a lower TCO than alternatives and with lower barriers to entry." That sort of thing. The non-crass view of it is that thinking about an existing strategy in a new way affects my overall development process.
[WWS] 2009-04-24I am no expert, but when I write a GUI app I structure in a sort of "Micky Mouse" MVC (MMMVC?) I structure it the following way, both mentally and in terms of laying out the code (e.g., in the program text I set off these sections clearly with comments.)
- SECTION 1, Model Definition: First I have a single array variable that I usually call "MODEL". This has all the data, names of databases, etc that might get passed around. DB connections etc are not made yet, though. There will usually be an element called FINIS (e.g. set MODEL(FINIS) 0); I will vwait on this being changed to end the script event handling. I use CAPITALS for sort of global variables that hold state like MODEL.
- SECTION 1.5, Utility Procs: We all know what these are -- something that uppercases something, etc.
- SECTION 2, Model Updating Procs: I then write proc's that access MODEL via an upvar statement. I do the upvar thing because (1) globals really, really annoy me and (2) it makes the procs easier to unit test. These proc's are used by the various widgets as commands (e.g. button .b1 -command {addOne MODEL}). Callbacks for fileevents get defined here too. One of these must update MODEL(FINIS) in order to exit the script.
- SECTION 3, Traces: Here go trace commands on the MODEL elements that update stuff. Usually they update various "views" of the data that are displayed by widgets when MODEL elements change. For example, if someone pushes a button, which in turn updates a counter, there might be a trace on that counter to redisplay something in a text widget.
- SECTION 4, Widgets and Inputs (event handlers): Finally I define the widgets using the "model updating procs" defined earlier as their commands, and usually pack them along with their definitions. Also, sockets or fileevents get set up here, with callback procs defined earlier. Widgets and callbacks NEVER cross update each other or any globals -- they update the MODEL through upvars, traces on the model then percolate the changes down to other widgets; this avoids headaches for me.
- SECTION 5, Execution and Loop: Finally we get to do something! Here is where real control starts. Since I usually run my scripts from the command line, I go ahead and use parameters passed in through the shell. Generally this section goes: check parameters, open stuff like databases, vwait on MODEL(FINIS) to handle events, after returning from vwait clean up and exit.
