John - And how do you manage/workaround cfargument typing and extends issues?
Mark On 9/13/05, John Farrar <[EMAIL PROTECTED]> wrote: > 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"> -- E: [EMAIL PROTECTED] W: www.compoundtheory.com ICQ: 3094740 ---------------------------------------------------------- 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]
