The description of problems related to a common store of information doesn't surprise me... although it's not an issue I've had to deal with personally... I'm not sure why... Most of the cf developers I've worked with don't seem to be heavy into modular code (custom tags / cfc's) ... they'll use them when someone suggests one or they find one on the devex, but they don't write their own, either because they don't know how or because they don't feel like they have the time or it's just not important to them. So... given that I suppose I should say I'm actually somewhat surprised that I haven't had the problem you described. :)
I suspect that the onTap framework if properly leveraged would help to mitigate the issue, because of it's self-documenting nature. You can print out the list of important variables in the framework (with descriptions) easily -- if any time you need to add something important you add it to the documentation before writing the code (it's a tiny file in a specific, easily found directory), then you'll always know if you're planning to use a variable name someone else has already used for something else. The same should also be true of user defined functions -- because they're all stored in a specific directory and their file names match their syntactical reference, it's easy to see if there's a name space conflict. With custom tags that's sort of "built in". But all the UDF's and Custom Tags in the onTap framework are self-documenting via a simple, human readable xml dialect also. relevant pages: http://www.turnkey.to/ontap/docs/index.cfm?netaction=impleme nt/registry http://www.turnkey.to/ontap/docs/index.cfm?netaction=impleme nt/libraries http://www.turnkey.to/ontap/docs/index.cfm?netaction=impleme nt/customtags http://www.turnkey.to/ontap/docs/index.cfm?netaction=spec Again -- requires a few extra lines of code (in this case documentation) similarly to the approach of requiring everyone to keep their methods within their own CFC's. UDF's in Tapestry still have to be loaded -- there's a custom tag that manages them and prevents duplicated includes (and resulting errors), and is somewhat similar to <cfimport> if not in syntax at least in spirit. It grabs out the relevant function file -- that file automates the process of including any dependant functions (so you don't have to keep a list of dependancies in your head), and stashes the requested function in the request scope. I suspect you could get better performance on MX by using the application scope to cache the functions, which wouldn't be a difficult modfication, but hasn't been done largely because I still want the framework to work on CF5 for now -- and hopefully that makes it a good framework for people currently stuck on CF5 but wanting to migrate to CFMX in the future. As to most developers... I'm not sure most of them care. heh. :) Obviously a lot of us do have strong preferences, and of course, mine are already apparent. I think most of the developers I've worked with in the past just use whatever is available or whatever is requested / suggested / recommended. Anyway... My 2c... I'd bet this thread would get a much larger response (a lot more commentary) on either the cf-talk or cf-community list if you want to forward it over that direction. Hope the list isn't getting tired of my dissertations. :) s. isaac dealey 972-490-6624 team macromedia volunteer http://www.macromedia.com/go/team chief architect, tapestry cms http://products.turnkey.to onTap is open source http://www.turnkey.to/ontap > I get the sense (from reading many of the posts) that many > developers prefer > the style of application design that has a wide variety of > custom functions > available in some type of application scope (i.e request, > response, session, > application, etc). Is this a true statement of most > developers. > Example: Isaacs phormat() function - having it available > to use in any > template in the app. without specially loading a UDF file > or CFC method > call. > For those that prefer to write apps in this manner - do > you share your app > space with any other developers? > For those who don't - same question? > I work with developers from all over the globe (my company > is setup this > way). We all share the same app space at a root level, > and every domain (75 > in all) points to a single Application.cfm at the root (or > at least is > required to be cfincluded). The "global" function style > has caused many > problems with developers in the past - so we dumped it. > Now developers are > required (or have the freedom) to create their own > functions and load them > when needed - but they cannot stay in an application > scope. This seems to > have eased the frustration with function names stepping on > each other, and > an overloaded app scope. But it does require a few extra > lines of code. > Just wondering. > _____ > Matt Knight ►Dresser Corporate Web Team ► Dresser, > Inc. ► w: 972 361 9943 ► > m: 214 213 4016 ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
