Hi David, Reading your comments on components has given me a lot to think about. So examining how I tend to look at components I find I break them down into two general areas:
1) as a repository for a core set of functions 2) as more or less independent sub-programs #1 - core functions I'd put Cannon Smith's object component in this category. I actually call mine 'Framework' and it's got a couple of hundred methods or so that generally do specific things. String, date, array, math, and so on kinds of things. A lot of listbox and form object methods. Basically all the things I will tend to use as part of my style. Heck, there's even a module made up of the methods from one of the hash technotes you wrote. The component has its own error handling system and the methods in it either refer only to other component methods or a plugin (which must reside in the database so those are pretty rare). The overall strategy is these are things the host database will call on when needed to enrich the life of the host. I also include some developer tools I find handy. I can drop this into a brand new structure and have most of what I need to get to work. #2) - sub programs In this ring we have more developed applications which really are nearly complete apps on their own. I expect these to manage their own errors and be well tested and solid. Bruno LeGay's component for uploading to AWS is one. Peter Jackobsen's Code Wallet is another that comes to mind. In contrast to the previous case I expect these to offer me a limited number of hooks or front facing methods. I always use compiled components. And I dearly wish 4D offered a pref that would allow me to have them appear with a different color from regular methods in the editor. So, how does this work when I'm actually using it? The methods in #1 are generally well tested. If something does throw an error I open the source code, fix it, recompile and restart. Or I write a local method to take over that function from the component. There are two ways to spot duplicated methods: 1) they appear as warnings in the complier and 2) I have a method in the component that will show me a list of them. I like being able to override the component with a local method. The problem is when I may write a local version of a method and forget to go back and update the component. I like being able to use aliases of components in the database folders. I keep 2 folders in the main folder for each 4D version: Component DBs for the uncompiled databases and Component Builds for the built ones. This way when I update one of my 'core' components all my databases are updated with the newest version because they all refer to that folder by way of aliases. This works for me in the large majority of cases. Somethings have never worked well in a component for me. Inherited forms - it would be really great if these worked but I haven't been able to make it happen. Functionality specific to a particular database has never seemed like a good idea either but I may not be thinking creatively enough. Though I guess it could be useful for some sort of licensing scheme. I have never expected or really wanted a component to share the same memory space as the calling process so that's not an issue for me. I actually like the black box approach they compel you to take. The final thing about components is to have some useful material in the comments because that's the only way to get a tip to show up when you're using it. I've been using an approach like Wayne talked about for several years and it's really great for components. Before building I run the macro and update the comments of all the component methods with the comments from the method. So nice to have that reminder of what params do what. -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
