From: Richard C. <rd_...@sb...> - 2003-12-09 21:25:27
|
Here's a question for us to discuss -- what kind of program would be the= ultimate teaching example for Zoolib? We instructional designers call that= an "exemplar" -- an example that captures the essence of what's being= taught. For example, when I rewrote Macintosh Programming Fundamentals for Apple, I= used a stripped down drawing application similar to MacDraw. Everybody was= asking "how do I update the screen, do scrolling, print, etc." and the= documentation didn't give a good example as it used the built in TextEdit= package that hid the mechanics of how to do all these things. But, as= another developer observed later, "every Macintosh application is, at= heart, a degenerate drawing application" so we had hit on the right= exemplar for the course. Since GUI programming is relatively common knowledge, as is the= model-view-controller approach, we wouldn't need to use the same example= today (and especially not with Zoolib.) I believe a Zoolib exemplar would= have a multi-part layout (probably different views of the same data), use= the internal database and/or networking, and have good reason to use= multiple threads. As a teaching tool, it should have fairly trivial= algorithms so we can focus on the UI. It should not depend entirely on any= "major" UI modules built in (e.g. the NPainter framework), as that doesn't= help people learn how to do the basics. And, ultimately, it should be a= simple version of a reasonably familiar application so we don't have much= of a learning curve for the app itself. I was thinking of a "contact manager" program -- one of those tools that= sales professionals use that combines an address book with reminders to= make contact (and provides a place to store notes.) That calls for a= multi-part layout -- a list of addresses, a selected address' details, and= notes on those calls. It's a natural for the database, and could be= extended to use a local "customer info" server. I could even see a use for= threads (as you type in a name, the DB lookup happens concurrently on a= thread.) But, this is a first thought and I'm open to suggestions. What do _you_= think? ...Richard |
From: Conrad W. <we...@on...> - 2003-12-10 17:28:34
|
>----- Original Message ----- >From: "Richard Clark" <rd_...@sb...> >To: <zoo...@li...> >Sent: 9. desember 2003 22:25 >Subject: [ZooLib-dev] Finding a ZooLib "exemplar" >Here's a question for us to discuss -- what kind of program would be the ultimate teaching example for Zoolib? >We instructional designers call that an "exemplar" -- an example that captures the essence of what's being taught. [snip] >I was thinking of a "contact manager" program -- one of those tools that sales professionals use that combines >an address book with reminders to make contact (and provides a place to store notes.) That calls for a multi->part layout -- a list of addresses, a selected address' details, and notes on those calls. It's a natural for the >database, and could be extended to use a local "customer info" server. I could even see a use for threads (as >you type in a name, the DB lookup happens concurrently on a thread.) >But, this is a first thought and I'm open to suggestions. What do _you_ think? > ...Richard Sounds like a great idea. I believe the buzz word is CRM (Contact Relation Manager) and they are getting hotter and hotter by the day. Microsoft has taken on the challenge and a.f.a.i have heard will soon release their .NET based crm. I have been a small part of one called SuperOffice that is now over 10 years old and still runs on a gui framework named StarView but very much extented and fixed by us over the years. It was even x-platform at one time but the Mac market never make it. I haven't yet put ZooLib to any practical use (goes for a great many other things as well!) but I have kept an eye on it and as I am interested in "contact managers", I'll be curious enough to study it. Cheers, Conrad Weyns ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ ZooLib-dev mailing list Zoo...@li... https://lists.sourceforge.net/lists/listinfo/zoolib-dev |
From: Andrew G. <ag...@em...> - 2003-12-12 02:13:30
|
On Tuesday, Dec 9, 2003, at 15:25 US/Central, Richard Clark wrote: > I was thinking of a "contact manager" program -- one of those tools > that sales professionals use that combines an address book with > reminders to make contact (and provides a place to store notes.) That > calls for a multi-part layout -- a list of addresses, a selected > address' details, and notes on those calls. It's a natural for the > database, and could be extended to use a local "customer info" server. > I could even see a use for threads (as you type in a name, the DB > lookup happens concurrently on a thread.) I like the idea. I had been thinking of a picture browser, akin to gqview, but that entails a lot of image-processing stuff which would swamp the more general aspects of an app. However, rather than using ZDBase I'd very strongly suggest looking at the tuplebase stuff. It manages freeform tuples rather than records from fixed-schema tables and all access is transacted, whereas ZDBase requires careful locking. The ZTB API and semantics remain the same regardless of the actual underlying implementation (locally hosted or via network socket to another process or host). It's been a couple of years since I've had a GUI app in development, so this examplar would very helpful in getting the ZooLib UI code updated -- it's become a little crusty in places (see TODO.html for specifics), and some architectural issues arose that I think I've now got solutions for; it would be good to work them out with new code that's still maleable. A+ -- Andrew Green mailto:ag...@em... Electric Magic Co. Vox/Fax: +1 (408) 907 2101 |