Its always better to pass application scoped variables in. And for session variables a cfc somewhere has to talk to session scope but limiting the cfc's that do this is a good thing. That is why the Session Facade is a popular pattern.
But if you feel like breaking the rules elegantly then Barney Boisvert has a good way to do it: http://www.barneyb.com/barneyblog/2005/09/27/the-encapsulated-hack/ Alan ________________________________ From: Henry <[email protected]> To: CFCDev <[email protected]> Sent: Wednesday, January 28, 2009 8:44:43 PM Subject: [CFCDEV] Re: Questions on Design of DAO, what is your version like? One more question. Does it store DSN in variables scope (via Coldspring constructor injection), or get it out from application scope? Anything wrong with getting DSN right out from application scope? Henry On Jan 28, 11:41 am, Alan Livie <[email protected]> wrote: > Hi Henry. > > You said 'The culture here at my work place is to use least frameworks as > possible' > > I have worked for employers like this and the best thing you can do is start > one-by-one introducting frameworks on low-risk projects or parts of your app. > Then over time as experience in the team grows you can add more frameworks > and spread them further across your applications. > > If they still don't want to use them you should still learn them as more and > more jobs require them. > > Alan > > ________________________________ > From: Henry <[email protected]> > To: CFCDev <[email protected]> > Sent: Wednesday, January 28, 2009 6:59:24 PM > Subject: [CFCDEV] Re: Questions on Design of DAO, what is your version like? > > I can understand Transfer could really rock! That's why I tried using > it for a Point-of-Sales-like system for my friend. However, when I > save the rather complex object (with onetomany and manytoone > relationships, that also has manytomany relationship), it throws an CF > exception in the Transfer code (not a Transfer exception that tells me > what I did wrong). It is so frustrating 'cause when Transfer works, > it is superb, but if it doesn't, it does too many magic for you that > you have no idea how to debug. > > The culture here at my work place is to use least frameworks as > possible. Before I work here, they used to use all store procedures! > No CFQUERY allowed! I took the risk of introducing the use of Model- > Glue, ColdSpring, and generated CFQUERY in DAO/Gateway for my last > project. My manager will still stare at me every time when ?init=true > timed-out due to the initialization of ColdSpring. With my rough > Transfer experience so far, it would be even harder to convince them > to use Transfer. > > Henry > > On Jan 28, 10:42 am, Bob Silverberg <[email protected]> wrote: > > > On Wed, Jan 28, 2009 at 1:26 PM, Henry <[email protected]> wrote: > > > > How come everyone uses Transfer... I don't, and I can't. > > > > Unfortunately, my application is complex enough that Transfer doesn't > > > fit the bill, and I've not had a good experience with Transfer so far, > > > because it tends to throw exceptions that I have no idea what I did > > > wrong at my part. I ended up spending the time to debug Transfer more > > > than getting things done. I'm really looking forward to CF9's > > > hibernate functionality. However, I'm glad that Transfer works for > > > many of you. > > > Hmm, perhaps many people use Transfer because it rocks! It's > > incredibly flexible, so I'm surprised to hear that you find that it > > won't work for you due to a "complex application". I'm guessing that > > a lot of Transfer users have pretty complex applications as well. > > There is a bit of a learning curve (hence the exceptions that you > > didn't immediately understand), but once you're over the hump it can > > be very productive. I will be pleasantly surprised if CF9's hibernate > > support is as easy and flexible as Transfer out-of-the-box. > > > I realize that I'm gushing like some sort of Transfer fanboy, so I'll > > shut up now. > > > Bob > > > -- > > Bob Silverbergwww.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
