Two Ways to Keep Up
1. Newsletter
Our newsletter policy:
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
2. RSS Feed
Are you missing out on RSS?Click to learn more.
|
Articles
 |
Blogs
|
VBScript Programmer's Reference
Discover the full power of VBScript. Windows Script Host, ASP, ADO, Microsoft Script Control, error handling and debugging, regular expressions, classes, FileSystemObject, Dictionary, script encoding, script components, and more.
Discover the full power of VBScript. Windows Script Host, ASP, ADO, Microsoft Script Control, error handling and debugging, regular expressions, classes, FileSystemObject, Dictionary, script encoding, script components, and more.
All content copyright 2000-2006 by the individual specified authors (and where not specified, copyright by Daniel Read). Reprint or redistribute only with written permission from the author and/or developer.*.
Programmer
Abuse.org
A Place to Vent
Tell your tale...
Abuse.org
A Place to Vent
Tell your tale...
| Link Exchange |
|---|
| The PC Weenies |
| ProgrammerAbuse.org |
| SourceJammer |
| Software Reality |
| Metalshell |
| Arabian Developer Network |
| StandardI-O.org |
| .NET 247 |
| Programmers Heaven |
| Developers dex |
Letter From Andy Tegethoff
Received October 30, 2002
Dan,
Enjoyed the latest installment of the developer.* column.
A few thoughts occurred to me while reading:
- Another big risk of too closely modelling a data structure in the UI is inviting too-tight coupling between the front-end and the underlying layers of an app. Taken to the extreme, this can completely invalidate the concept of an N-tier architecture by essentially presenting the data layer to the user. Not to mention (given my familiarity with the example you provide in the column) the horrors of trying to deal with these coupling issues--a task which essentially necessitates a full tear-down and rebuild to fully complete.
- The notion of employing experienced developers to construct a UI is worth underlining. As you say, every language/IDE has its quirks w/r/t how UI elements should be implemented. Having recently joined the Java camp, one of my key concerns was working with Java GUIs (which in my experience were inevitably lame). I erroneously believed that inherent weaknesses of the Swing/AWT architecture were to blame, but I've come to realize that you can build a very effective GUI with Java--ONLY IF you are very familiar with the ins and outs of Swing (a subject to which many large books are dedicated). On the flip side, I've encountered many a sorry Visual Basic GUI based on the same problems. It's all about experience with a particular technology, because the myriad tricky little behaviors just can't all be documented.
- Also on that point, but from a project planning POV, I find some wisdom in sort of "disconnecting" the development of business logic and/or data layers from UI development. Meaning that the various developers or teams involved in each task should ideally have a "black box" perspective on the other efforts. Obviously on a small team everyone's hands will likely end up in every pie. But in a medium to large team format, this can enforce better coupling institutionally.
Thanks for more good words. Keep 'em coming.
Andy Tegethoff, MCP
Senior Consultant
Pallas Technology