Justin, A possible approach to take here is to have a listener that acts as a manager for all of the sub-atomic parts of the transaction, passing the event on to each if necessary in turn (I know this sounds like what you were hoping the framework would do for you). The manager can then deal with the transaction control and you still retain the ability to have the constituent parts act as listeners if necessary in other parts of the application.
Andr� > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Justin Balog > Sent: 14 October 2003 17:25 > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Mach-ii Managing Transactions > > Thanks, > > I understand they are not analogous to fuseactions, and I thought events > were completely distinct but sitll under the scope of the request that > initiated them (which was the primary reason I began to research the > framework)? Basically, my situation for chaining events is as follows. > This > is a very 'English' description of it....but its what needs to happen at > some level. > > 1) Click the Default Button on a traffic ticket. (Precipitated Actions > Follow) > -Creates A PDF sends to active PDF spooler and is printed out on > network printer > -Create audit action and records that the letter was > generated > -Adds $45 to traffic fine > -Create audit action that the fine was added > -Possibly Generates Warrant Depending on nature of traffic offense > -Creates audit action that the warrant was created > -Updates the Traffic Ticket Record To send to DMV > -Creates audit action that the record was updated and sent > to DMV > Process Ends? > > As always I appreciate the feedback Barney. > > Justin > > > > > -----Original Message----- > From: Barney Boisvert [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2003 10:15 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Mach-ii Managing Transactions > > > I aim to structure my apps so that any atomic action (with relation to the > database) always happens within a single call to a listener. Depending on > how you structured your app, that listener might house the CFTRANSACTION > tag > (but probably not), or it will be within a method that the listener calls > on > a CFC at a lower level. > > Events in Mach-II are not analogous to fuseactions in FB4, if you're > familiar with both. Events are completely distinct actions, not pieces of > an action that can composited together. It may happen that you need to > fire > several events in the handling of one HTTP request (usually the case, in > my > experience), but each event is still a stand-alone action to a fairly high > degree. > > About the highest level of chaining between actions that I ever use is to > pass content from a public event to a private event that applies a layout > to > the content (adds page-level HTML elements, perhaps global nav, etc). > > Not implying that that's the right way to do it, of course, but it's > worked > very well for my thus far, and directly addresses your problem, so I > thought > I'd share. > > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Justin Balog > > Sent: Tuesday, October 14, 2003 8:51 AM > > To: '[EMAIL PROTECTED]' > > Subject: [CFCDev] Mach-ii Managing Transactions > > > > > > > > Howdy, not to turn this into a mach-ii list, but I know some > > folks out there > > are using it. I was wondering how everyone is handling transaction > > management. If I handle one event that does some data processing, then > > announce another event that does some data processing, and the > > second event > > fails, how can that be all grouped under a single transaction? > > Can I handle > > this via the <plugin> preProcess() and postProcess()? Any feed > > back will be > > helpful. > > > > > > Thanks, > > > > Justin > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
