Sure, I sometimes do the same, though usually I'll just put a dump into the CFC and dump out the whole this scope so that I can see everything from the inside, including the methods and the variables scope.
On 10/4/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > Thanks Brian, actually feels kind of nice to be wrong, at least when a > better suggestion comes after it =) > > I am completely with you on passing a reference to the object as > opposed to passing just the instance data. Passing the instance > bypasses all the great advantages of business logic rich beans. > > I currently just use these getInstance() / getMemento() functions when > I need to dump the value of every property of an object. Nothing for > production, just purely for debugging. > > Like the other day I was setting some properties of a CFC and saved it > to a database, however the values I was setting and the values in the > database where not matching up. Wanted to find out if it was the Bean, > the DAO or perhaps some trigger in the database. I was able to quickly > see that the data was being changed somewhere in the Bean by simply > doing a <cfdump var="#bean.getMemento()#"/><cfabort/>. I did the dump/ > abort right before making the DAO saveRecord() call so knew it was > something within the Bean CFC. Was able to just keep moving the dump/ > abort up a few lines in the code manipulating the Bean and saw exactly > where the data was being changed. It actually turned out to be a real > dumb logic error on my part which I won't get into here as it is a > lengthy, rambling story. > > > On Oct 4, 8:46 pm, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > > Yes Greg, you've got this one wrong. ;-) getInstance() is usually a > static > > method that you call on a class to return an instance of that class. > This is > > done when you make the constructor private (which, in Java, is almost > always > > a smart design decision because it allows you to encapsulate the > creation of > > the object and maintain control over what happens during instantiation). > > > > You can call it getMemento(), but I'm somewhat concerned about the > > increasing popularity of doing this. Under what circumstances do you > really > > want to return the internal state of an object? I think in most cases it > > would be better to pass the actual instance around, so that other code > can > > call methods on the object and you maintain encapsulation and reap the > > benefits of any business logic that lives in the bean. > > > > On 10/4/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Hey Paul, > > > > > You bring up another problem I just recently encountered - whether to > > > call a method which returns Variables.instance (a struct that holds > > > all the instance data) getInstance() or getMemento(). > > > I have been calling it getInstance(), however lately I have thought > > > about using getInstance() in my Singletons in order to return them, as > > > I think it is some sort of Java standard. I could be totally wrong on > > > this though. I understand that getMemento() comes from the Memento > > > pattern. > > > > > Any thoughts, getInstance() vs getMemento()? > > > > > - Greg > > > > > On Oct 2, 1:26 pm, "Paul Marcotte" <[EMAIL PROTECTED]> wrote: > > > > Hi Greg, > > > > > > I've experimented with composing DAOs inside Beans. I don't know if > > > there > > > > is a specific problem with using dao.saveRecord(this), but if you > think > > > > about what "this" is, you're going to be passing the Bean and the > > > composed > > > > DAO into the composed DAO, which just seems weird to me. For my > > > > implementation, I use dao.save(getInstance()), where getInstance() > > > returns > > > > the variables.instance struct. You can call getInsance() by another > > > name > > > > like getMemento() or something similar. To me, passing a struct off > to > > > the > > > > DAO is like passing a poor man's value object (which, in my > > > understanding, > > > > is an object wrapper around an instance struct with no get/set > methods.) > > > > > > Granted, I'm not a design patterns guru, so I'll defer to Brian and > Tom > > > on > > > > this point... > > > > > > Paul > > > > > > On 10/2/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > Definitely right, it could be overkill. Wasn't looking at this for > a > > > > > specific application though, just some generic methods / > conventions. > > > > > > > btw, in the quick examples posted, running dao.saveRecord(this) > *is* > > > > > passing the dao a bean, assuming that dao.saveRecord(...) is being > > > > > called from within the bean itself. > > > > > > > On Oct 2, 1:38 am, Alan Livie <[EMAIL PROTECTED]> > wrote: > > > > > > Or pass a bean (or an ID for deleting maybe) to your DAO's > methods. > > > > > > > > Not sure if a service layer AND managers would be overkill for > your > > > > > > application. It depends on the size of it and how large you > expect > > > it > > > > > > to grow. > > > > > > > > Suppose it's nice to have maximum flexibility though. > > > > > > > > On Oct 2, 4:11 am, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > > > Thanks for the posts Brian and Tom. Definitely cleared up a > bit > > > for me > > > > > > > and also reinforced some of the ideas I have been having > lately. > > > > > > > > > @Brian - I feel the same way as you about the extends and IS-A > > > > > > > relatonships. That is what got me thinking about injecting the > DAO > > > > > > > into the bean and running something like dao.saveRecord(this). > > > > > > > > > @Tom - Thanks for the link, I will have to read it more > thoroughly > > > > > > > later. > > > > > > > > > Right now I am leaning towards Tom thinking of a Service layer > > > being > > > > > > > more in charge of the various managers. Am going to have to > read > > > up > > > > > > > some more articles on it. Perhaps finally dig into some more > > > Martin > > > > > > > Fowler or something. > > > > > > > > > Again, thanks for the help guys! > > > > > > > > > - Greg > > > > > > > > > On Oct 1, 2:58 am, Tom Chiverton <[EMAIL PROTECTED] > > > > > wrote: > > > > > > > > > > On Sunday 30 Sep 2007, [EMAIL PROTECTED] wrote: > > > > > > > > > > > Part-1#comments) and it made me remember that I am > confused on > > > > > exactly > > > > > > > > > what Service CFCs are. I posted this question to the blog, > > > however > > > > > > > > > would really like to receive a lot of feedback and > different > > > > > opinions > > > > > > > > > on this. > > > > > > > > > >http://rachaelandtom.info/building-coldfusion-services-2 > > > > > > > > > > > I have been getting more into CFCs and proper OO > methodologies > > > > > lately, > > > > > > > > > 90% of it is all making sense and every day more and more > > > becomes > > > > > > > > > clear, > > > > > > > > > > Doing it day and day out sure helps :-) > > > > > > > > > > > In my mind a > > > > > > > > > Gateway CFC deals with the database when retrieving more > then > > > 1 > > > > > > > > > record. > > > > > > > > > > That's how Reactor uses them, sure. > > > > > > > > > > > My question is - I find I need to have a CFC that > co-ordinates > > > > > actions > > > > > > > > > between multiple beans, takes some sort of action, > performs > > > > > business > > > > > > > > > logic on 2 different beans that may represent 1 class or > > > perhaps 2 > > > > > > > > > classes (eg/ maybe 2 staff benas or 1 staff bean and 1 > company > > > > > bean). > > > > > > > > > I am wondering - would this be considered a Service CFC? A > > > Manager > > > > > > > > > CFC? Something else? > > > > > > > > > > Sounds like a Manager to me. > > > > > > > > A Service would deal with the mechanics of locating the > thing to > > > do > > > > > the work, > > > > > > > > getting it invoked and the results passed back to the > caller. > > > > > > > > > > -- > > > > > > > > Tom Chiverton > > > > > > > > > > **************************************************** > > > > > > > > > > This email is sent for and on behalf of Halliwells LLP. > > > > > > > > > > Halliwells LLP is a limited liability partnership registered > in > > > > > England and Wales under registered number OC307980 whose > registered > > > office > > > > > address is at St James's Court Brown Street Manchester M2 2JF. A > list > > > of > > > > > members is available for inspection at the registered office. Any > > > reference > > > > > to a partner in relation to Halliwells LLP means a member of > > > Halliwells > > > > > LLP. Regulated by The Solicitors Regulation Authority. > > > > > > > > > > CONFIDENTIALITY > > > > > > > > > > This email is intended only for the use of the addressee > named > > > above > > > > > and may be confidential or legally privileged. If you are not the > > > addressee > > > > > you must not read it and must not use any information contained in > nor > > > copy > > > > > it nor inform any person other than Halliwells LLP or the > addressee of > > > its > > > > > existence or contents. If you have received this email in error > > > please > > > > > delete it and notify Halliwells LLP IT Department on 0870 365 > 8008. > > > > > > > > > > For more information about Halliwells LLP > > > visitwww.halliwells.com.-Hidequotedtext - > > > > > > > > - Show quoted text - > > > > > > -- > > > > Paul Marcotte > > > > Fancy Bread - in the heart or in the head?http://www.fancybread.com- > > > Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
