That's one way to do it. I'd argue that you shouldn't be calling Reactor from within your Circuit XML at all. I would recommend creating a service layer to encapsulate your model (which includes Reactor). That way you can use it from your Fusebox circuits or your remote facades. Basically, the model (including Reactor) should never know or care how it is being used. Could be Fusebox. Could be Model-Glue. Could be Flash Remoting. Could be web services. Could be AJAX. If letting all of these kinds of use of your model sounds like it is going to take a lot of work, then that means you should think about refactoring your model. Because in a well-encapsulated model, allowing for any or all of these takes almost no effort at all.
I wrote a blog entry on AJAX interaction with the model yesterday in response to this and other questions on the blogs and lists. Have a look if you like: http://www.briankotek.com/blog/index.cfm/2007/7/25/AJAX-Data-Requests-vs-AJAX-Content-Requests I also have a presentation and sample code on Framework Agnostic Models that I gave at this year's Frameworks conference. It might make the idea of a neutral model more clear: http://www.briankotek.com/blog/files/framework_agnostic_models_presentation_code.zip Hope that helps. Brian On 7/26/07, David Phipps <[EMAIL PROTECTED]> wrote:
Thanks for the info Brian. I'm sure it makes sense and I think I understand! So, just to clarify, if I have a circuit (fb5.1 app) called Districts which contains all the fb code for handling Districts. Instead of calling Reactor directly in fb I would create 2 cfcs one could be DistrictFacade.cfc and the other could be DistrictRemote.cfc. Then any ajax calls would hit DistrictRemote which in turn would hit DistrictFacade and this would then make calls to Reactor? Am I almost there? Cheers, Dave Brian Kotek wrote: > Dave, short answer: no. Reactor is an ORM framework, and what you are > looking for is a remote facade. > > In my applicaitons, Reactor is not even "publically accessible". All > requests from the Controller go through a Service layer. Same goes for > AJAX reqeusts (or Flex requests or web service requests for that > matter). I create remote facades for my Service layer components > (actually I have ColdSpring automatically create them) and the incoming > requests hit that remote facade. So basically: > > 1. AJAX call hits remote facade, which has only certain methods > available for remote access, and also may apply special pre- or > post- processing to the requests, such as serializing or > deserializing to JSON, etc. > 2. remote facade calls service layer component > 3. service layer component calls reactor > 4. query returned by service layer to remote facade > 5. remote facade converts to JSON (or whatever) > 6. remote facade returns results to AJAX caller > > Hopefully that makes sense. > > > On 7/25/07, *David Phipps* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > > I am thinking about adding some ajax functionality using ajaxCFC and in > the past I have written a separate cfc, that extends ajaxCFC, and this > contains the methods used for the ajax calls. > > Is there a way to plug/link ajaxCFC into reactor so that I don't have to > write a separate set of methods in another cfc? > > Many thanks, > > Dave > > > -- > > _______________________________________________________________________ > David Phipps, Director > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > Chapel Studios / London > T +44 (0)20 7100 6980 F +44 (0)20 7100 6981 M +44 (0)7931 375040 > New Broad Street House, 35 New Broad Street, London, EC2M 1NH, UK > > Visit our website: http://www.chapel-studios.co.uk > > _______________________________________________________________________ > > Chapel Studios is a limited company registered in England. The > information in this email is confidential, intended solely for the > addressee, and may be legally privileged. If you are not the > addressee > or authorized to receive this for the addressee, you must not use, > copy, > disclose or take any action based upon this message or any > information > herein. If you have received this message in error, please advise > the sender immediately by reply e-mail. > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- -- > Reactor for ColdFusion Mailing List > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- -- > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- > Reactor for ColdFusion Mailing List > [EMAIL PROTECTED] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- -- _______________________________________________________________________ David Phipps, Director [EMAIL PROTECTED] Chapel Studios / London T +44 (0)20 7100 6980 F +44 (0)20 7100 6981 M +44 (0)7931 375040 New Broad Street House, 35 New Broad Street, London, EC2M 1NH, UK Visit our website: http://www.chapel-studios.co.uk _______________________________________________________________________ Chapel Studios is a limited company registered in England. The information in this email is confidential, intended solely for the addressee, and may be legally privileged. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based upon this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [EMAIL PROTECTED] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [EMAIL PROTECTED] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
