This is what for lack of someone telling me a socially more accepted term for it... an API. We have built into SOS a more robust API with these exact goals in mind. In some ways you might say that it violates encapsulation, and we are OK with that. The trade is a net gain not a net loss. There is too much talk about trade offs rather than net gain vs net loss. The real question is not just trade offs... but what is the net gain?
This allows us to create universal variable structures to contain settings for sites, user, etc. It also allows us to create cached variable settings for applications, thus speeding the applications ability to handle a more granular application configuration. Using these features combined we are able to program our web sites more like an OS in concept than a traditional paradigm. Because of that those who have seen my presentation on SOS are familiar with my call to leave the "Dos Ages"! (P.S. SOS is free but we are working on version 3 now, so DL Police will have to give up shooting me down for being a profit monger, heh. Yet, the code isn't public yet... if anyone is interested in helping "BUILD" this next version, or talking about it they are welcome to talk to me.) On a distributed application site one of the big advantages is this common framework and API lets you install in any directory without having to configure it's location. You do have to configure the URLs though... that's a security issue, so we went with that one. It also lets you create different apps in different methodologies by creating plugins to manage the code execution inside of the system. If you need to customize the core, it is extensible and that is plain to achieve. So my goal was to let you write your app in your style of programming and write my app in my style. (Or update a style without making them so they cannot run on the same site, and create a situation where old work is obsolete.) The result is you and I should be able to write applications that are disconnected from controlling the authentication and managing the presentation. Our apps should be managing data (through CFCs preferably but not by requirement, so someone can build simple apps and ramp up to better methodologies without current works becoming obsolete), manage logic and content. This is accomplished by consuming API features to make our applications portable. This one seems to have escaped the CF community. We have portable methodologies, but not portable apps. I am sure others could do this type of thing also... and it's likely someone has. It's amazing to me that we don't see the benefit that windows/mac/amiga brought to the desktop. We are still thinking like DOS programmers at large. </rant started="you choose where it degraded to a rant" mode="OT" value="user selectable"> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Tuesday, September 13, 2005 2:33 AM To: [email protected] Subject: RE: [CFCDev] Factories and mappings Guys, We have a framework that allows us to create very complex intranet modules, which leverage of cfc's. The problem that we faced is the same as what people are discussing here, so our solution was mappings. But we would define in the application scope something like this. <cfset Application.SiteName = "AustralianBridalDirectory" /> <cfset object = CreateObject('component','#Application.SiteName#.system.security') /> Our only problem is that the extends doesn't work this way. But we deploy every intranet this way that we design, makes maintenance easier from our perspective. So when we create a new intranet, we are only changing one line of code. Regards Andrew Scott Analyst Programmer CMS Transport Systems Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9699 7988 - Fax: 03 9699 7976 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
