John W. Colby
jwcolby at colbyconsulting.com
Wed Mar 10 21:37:58 CST 2004
>Evolution is a valid development method, especially when the path ahead is not clear. I often find, though, that doing an informal design using pencil and paper saves time. It helps separate needs from wants. Do I really need 3-D animated text on my Message Box replacement? It may be vital, but if it isn't, leave it out for now. Which is part of the goal of this discussion. I would love to assist our members in avoiding what I went through! I learned about frameworks by using the toolboxes that Borland provided back in the mid to late 80s when they were trying to promote Turbo Pascal. I did not truly understand the concept, I just used the toolboxes. Of course back then Turbo Pascal didn't have OO, but once it did, suddenly the concepts behind a framework became a little clearer as I studied OO, inheritance, subclassing, and all that stuff. Then came Access with objects, methods and properties but strangely... no inheritance. 8-( Sigh. I was so busy trying to absorb the Windows / Access methodology - events, drag and drop design, code behind forms etc - that I kind of lost site of the framework concept and simply designed a library. Eventually as I added functionality to the library I realized that I was designing stuff that was generic enough to be reusable, and slowly a VERY crude framework just started emerging from the muck. Unfortunately I didn't understand classes and indeed had never even heard of Withevents so I did things like collections storing collections keyed on form names containing pointers to controls... Really messy stuff, but as I said I didn't understand classes; and it worked but REALLY MESSY. Then a certain Russian gentleman who shall remain unnamed - well ok, it was Shamil Salakhetdinov (shamil at smsconsulting.spb.ru) - started popping up in AccessD and dropping little tidbits and teasers about Withevents. Even with years of programming and indeed years of Access, for some reason it took me three tries across a 1.5 year period of time to finally understand Withevents, and Withevents gave me a reason to use classes so I had to learn them. Once I had a "good grip" on those two technologies (and I use "good grip" loosely), I launched into a redesign of my original "framework" (which I use VERY loosely), eventually building C2DbFWA2K which is my current framework. It is heavily class and Withevent based. Unfortunately as we all know, if we are going to grow we are going to do things that simply don't make sense in the light of what we know today. My 2nd generation framework does things I wouldn't do today and I think it will be worthwhile to do a third generation. Furthermore I'm beginning to see how some of this stuff could port rather nicely to .net! This discussion allows me to do a design while "talking out" the design concepts with a group of developers many of whom are more experienced than I am. IF I can get those developers to pipe up and tell me when I am doing stupid stuff, this third generation framework may be a solid piece of work. Not that my last one wasn't, I am quite proud of what it does, but it can be much better. And finally, this discussion allows me to encourage a whole group of "youngsters and not so youngsters" who have not ventured in to these waters to do so. I think I (or hopefully WE) can save some of our group members a lot of pain that they don't need to experience. Classes, Withevents and Frameworks are subjects that are just very difficult to find information on, at least in the Access environment, yet are technologies that once understood completely changed the way I develop applications. It would be nice to get a strong core of our members using this stuff for the very selfish reason that then I will have others to bang ideas off of and "borrow" ideas from! John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ken Ismert Sent: Wednesday, March 10, 2004 9:11 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Framework Discussion - Who's following this John, >Yea... in a perfect world. Unfortunately for most of us a framework is not >a project which we spec out and write, but rather a living entity that we >add functionality to on a weekly basis. Thus feature bloat is an inherent >part of doing business, and there is never a finish, much less a timely one! Evolution is a valid development method, especially when the path ahead is not clear. I often find, though, that doing an informal design using pencil and paper saves time. It helps separate needs from wants. Do I really need 3-D animated text on my Message Box replacement? It may be vital, but if it isn't, leave it out for now. Of course, a framework implies an organization of function. So, how do we organize a constantly changing function set? By providing standard methods of extending the framework. Careful design here can have an enormous payoff. This is where interfaces can play a role. > ... I think it is important to NEVER accept the limitations of your >platform. Much of what my framework does is nothing more than an attempt by >me to program around the limitations of Access ... Removing arbitrary limits is a worthy pursuit. Don't like the [Forms]![Form]![Control] method of synchronization? Replace it with your own global parameter collection. Want to enforce standard behavior for ComboBox NotInList events? Write an event-sinking class that provides that functionality. All good. The tools of object programming and abstraction give us ample power to work around such limitations. It gets a little trickier when dealing with the platform's warts, like not automatically terminating an out-of-process object. Here, limits can't be satisfactorily removed, and the best we can offer is workarounds and advice. There are certain things the platform will never do gracefully. I tend to draw the line at fixes/extensions that involve: * Risky VB programming practices (handling Object pointers as longs, LSet abuse, etc.) * Extensive use of the Windows API. Just way out of my field of expertise. Should be delivered as a .DLL, anyway. * Reliance on version-specific quirks or bugs * Undocumented features (although some, like Decompile, are essential) -Ken Biedermeier - a German furniture style of the early-to-mid 19th century. A break from the highly decorative styles which preceded it, Biedermeier emphasized durable construction, the intrinsic beauty of the wood, restrained decoration, and simplicity of design. Some of the pieces belonging to this style have a very modern look to them. -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com