Hi, I read some stuff about the singleton-pattern, that helped me understanding that when mach-ii calls the configure method of a listener (first) it instantiates some objects, defined in the configure method, and that theres only one instance in application scope (hu, didn't know about the singleton-pattern before, I was frightened..) thats like the principle of the singleton-pattern.
right, isn't it? (I looked at the framework-code (mach-ii.cfm) to confirm that thought.. ) so, I just looked at my listeners and made some small changes. There were sometimes private (var) instances created in listener funtions, so I put them (nearly) all in variables-scope in the configure method. that theres only one instance. But the problem is now, in my service-layer/s there I create in nearly every method an instance of e.g. a gateway or dao again. although it already exists somewhere in application-scope. Now I want to expand my app, the service-layers, using the singleton-pattern.. (I know.. would have been better to do that before) So, when an instance of the service-obj is first created, store it in app or server-scope and later re-use it. But I don't know whats the right way to go here. Maybe some instances already exist (dao/gateway) in app.scope because of the initialization of the framework/listeners. What about calling some kind of manager that checks for an instance created by the framework and created one itself if there is none or gives back the existing one. hmm, or am I thinking the absolute wrong way here? maybe.. some advice would be great (sorry, it's not so easy to explain, also I got almost no german stuff to read about) yes, I know there are several infos in the threads at the cfcdev-mailing-list. sure it helped me to get a little in it, but it would be interesting how others handle this, especially with mach-ii.. actually I don't know how to solve that problem. thank you for your replies sebastian -- Sebastian Mork <[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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
