DWUTKA at marlow.com
DWUTKA at marlow.com
Tue Mar 16 14:03:20 CST 2004
I see what both of you are saying on the issue. Let's not turn this into another bound/unbound discussion. It is all dependant on what type of projects you work on. If you find that you are building the same functionality into multiple projects, then a framework concept works great, because you are saving development time by doing it once. However, if you find that you are creating completely different projects, all of the time, then a framework doesn't help that much. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Dettman Sent: Tuesday, March 16, 2004 8:07 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects John, I'm not sure what you think I mean by "overloading", but what I'm saying is that you have a choice: You either build numerous classes to handle specific behavior or you overload a single class with more properties and methods to make it handle more then one type of behavior. <<If a popup calendar floats your boat, build one and tie it in to the text box class. Have a UseCalendar property that you set the "turns on" using that calendar for exactly the instances where you want a calendar. However it is that you managed to program the text box to use the calendar in some form somewhere, that same exact code will work in the text box class. Except that once added to the class it is available to any text box anywhere in the app. Set your UseCalendar property and boom... that text box will use the calendar. This isn't magic, just engineering effort applied to the system rather than to one control on one form.>> And this was exactly my point. Your choice was either to create a new class in the Framework to handle a text control with a popup calendar or add properties and methods to a single class so it can do both jobs. <<Or are you perhaps telling ME THAT I SHOULD NOT DO THIS but it is just fine that Microsoft does it?>> I'm not telling you do to anything. I was trying to add to the discussion, pointing out that performance is based on design decisions that are made in the framework. You are taking an OOP approach and the same fundamentals apply no matter which language your dealing with. I don't understand why your taking this so personally. I never said that what you were doing was not worth it. I was discussing frameworks in general. This has nothing to do with me leaving Access for VFP, which I have not (I still use both tools on a regular basis). I would love to see someone do a commercial framework for Access. But after 10 years of existence, one has to ask themselves why there are not a truck load of them already. You asked for input about the design of frameworks and I've brought up a few issues (performance and distribution of new versions). If you don't want to address them and explore these areas then fine. But if that's the case, then don't ask for the input in the first place. Jim (315) 699-3443 jimdettman at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby Sent: Monday, March 15, 2004 9:34 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects Jim, > So you'll end up with lots of classes, unless I misunderstanding your intent. For example let's start with a base text box class. In a typical app, you can have text boxes that can be used for: 1. Text input 2. Input of a short date 3. Input of a short date and time. #2 and #3 are variations of #1 and contain some of the same behaviors and methods. So at the frame work level, I'm going to provide three classes or I'm going to do one class (text box) and overload it with properties to accomplish #2 and #3. But what your not doing is starting with #1, then creating #2 and #3 based on #1. Lets back up a minute and discuss this from a logical perspective. <<snip>> -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com