sheesh! you ask a simple question and you get war 'n' peace! is nothing simple anymore?
Barry Beattie CF Web Developer Alpha Business Systems [EMAIL PROTECTED] � Ph: +61 07 3216 0999 � -----Original Message----- From: Scott Barnes [mailto:[EMAIL PROTECTED] Sent: Thursday, 17 June 2004 4:12 PM To: CFAussie Mailing List Subject: [cfaussie] Re: using function libraries within CFC's Hi All, Thought I'd insert my 2c on how I'd approach it :) Personally my thoughts on a UDF vs CFC are this: CFC = Model layer UDF = View Layer. Simply put, the difference between a UDF and CFC is one doesn't have the CFCOMPONENT tags wrapping it ? or am i on crack. The framework I've been pitching here basically is that we have a lot of objects that get instatiated through-out the life of the application. On top of that we have various payable modules (ie optional installs) that use global objects and sometimes module specific objects and rather then creating then dumping each page request, we as typical to most, decided to now store these in a shared scope *currently server scope*. Now, when talking about the objects, these objects work in a plural sense, in that we wouldn't store all singular objects in the server scope: i.e. Blogs = Server Scope Blog = ??? Scope Entry = ?? Scope Inside the Blogs Object, it knows where to store the "Blog" entities, and only it knows, so in order to access data within each blog you go through the Blogs Facade initially. Now, getting back to Barrys Question of "how to" use a UDF within the context of a CFC? as per my above thoughts in that "..don't cross the streams.." (heh see Ghost Busters). I'd wrap these UDF's into a Component called Kernel personally. In our Framework here, we have a Server.Kernel Object setup, this is the brain behind our entire process, without the kernel the application can't run *much like an O/S, without the kernel.dll we are [EMAIL PROTECTED] The kernels single purpose in life is to handle routines we commonly would take for granted in other languages (ie import class per object etc). It *could* also be a source for say QueryToStruct() methods etc that sort of extend our core FUNCTIONS within CFMX server itself? up to you where you store it in the overall Server.Kernel Branch Now to access the Server.Kernel within the context of a CFC, I'd personally alias the Server.Kernel with request.Kernel that way if you do decide to shift the Kernel into say Application scope, you can but won't impact on the code through out as they always look to the request scope. (Could someone also jump in and tell me if this is a memory issue in that does it duplicate things? i know that if you did request.Kernel.monkey = true, server scope would also adjust itself as they are the same, but on a low level view of things? is this bad?) We personally instantiate the Server.Kernel on a dry run, in that the first user to access our applications will do a once off initialization script which instantiates needed Objects (ie Kernel, Factories etc) while also reading any configuration xml files (ie DSN, Package Paths, file upload paths, Skin Settings etc). Inside this Initialization script, is where you would alias your initial Shared scope eg; Server.Kernel = createObject("component","packages.kernel.controller"); request.Kernel = Server.Kernel; I'd also like to point out that another reason for the Kernel to exist, is to basically emulate the "import" concept. In our situation we have various Modules, and keeping all of our "plural" objects in Server Scope on the first hit, can be an un-needed and at times maybe cumbersome routine. So rather then doing an eat all, we do an eat what you need concept. So when a User first runs a Module within our application, that module has a manifest of objects it needs in order to run, so the first person to run that module will setup the objects for everyone else. Now in this process it would check to see if that object exists in our Server.Factory (or whatever you want to call it) if it does, cool its loaded already move on, else load it. This also happens inside various CFC's in that if a CFC uses another object in a package path, it too will never assume that objects already loaded, but instead hit the Server.Kernel upon its construction and inform it that it too needs to make use of a object(s) and that "please load them if needed because later on I will use them" Now it would be cool to simply be able to Import at the top of every CFC or .CFM file for objects so that we aren't constantly creating and killing objects per page context, but for now this routine seems to work and will reduce the expense of creating objects constantly whilst still allowing the objects to not only be used for a specific Application but future applications. So.... I'd personally lock all Data manipulation UDF's inside a CFC of some kind, and any HTML/VIEW specific UDF's would be kept separate and pretty much CFIMPORTED per page even... ie I've been taught and tend to agree, that HTML inside a CFC is not nice, as this is your Model Zone.... The Book signing for this post will be tommorow too. Regards Scott Barnes Senior Web Developer Alpha Business Systems 1/31 Thompson St Bowen Hills QLD 4006 Ph +61 07 3216 0999 http://www.alphabus.com.au Robin Hilliard wrote: > > 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/ --- 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/
