Hi Barry,
I would go for option 1 because this provides the best encapsulation (not so much for instance variables, but for private helper functions that the public functions in your library may require now or in the future). This said, you need to provide some sort of caching to avoid recreating the library CFC on every request (createObject is a very expensive function performance wise).
As long as you don't use or correctly lock instance variables in the library you could (as you suggested) store a single instance in a shared scope and put some code in Application.cfm to check for its existence (locked) and instanciate it if it's not there (locked again).
If the library needs some state for some reason or the locking bothers you/becomes a performance bottleneck there are other more complex solutions. For example, I've written a framework that pools cfc instances in shared scopes and hands them out to requests for their exclusive use (no locking required by the request code) after which they are reset and returned to the pool. This makes it possible for an entire request to an application written entirely in cfcs to execute without ever calling createObject (and therefore very fast). Part of the framework allows your request code to "import" a cfc to use as a library, which will only pull a single instance out of the pool and use that same instance every time that cfc is "imported" over the course of the request. The framework is being used in a production Flex/CF app, if you're interested I can send you the framework code as-is, although with the big caveat that there is no documentation (yet).
--------------------------------------------------- Robin Hilliard Consultant Rocketboots Professional Services for Macromedia Technologies +61 418 414 341 ---------------------------------------------------
Barry Beattie wrote:
hi all
what's the current "best idea" when it comes to allowing CFC's access to sitewide UDF's (eg: string manip, custom queryToArrOfStruct, etc)
- use a "has-a" idea for the CFC (and then check if the other CFC exists)? - use a straight cfinclude within the CFC (and then worry about paths/mappings)? - add them to each CFC as private methods (and have a million versions)? - extend each CFC from a base that has the UDF's in them (and bloat some CFC's for no reason)
using this as a guide
<quote src="http://www.sys-con.com/coldfusion/article.cfm?id=655&count=5087&tot=4&page=2";>
So what rule do I go by when making this determination? I ask myself the following questions:
1. Do I have a CFC that the function is directly related to?
2. Does the function access a database or another file?
3. Do I need to call that function directly from Flash?
4. Do I want/need to call that function as a Web service? If any of these are true, I put it in a CFC. </quote>
in this case, I've got 4 NO's.
I was first thinking of putting the functions into some CFC's within server scope but I'm stuck on the best trigger to load create them from new/reboot, without filling up the Application.cfm.
any thoughts/suggestions? thanx barry.b
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
