Actually, I was a swimmmer before programming. Paid my way through school, which was nice, but the hours sucked. Nothing like getting up at 5:30 every morning to go swim in an outdoor pool with ice on the deck. Kept me in better shape the driving a keyboard though. ;)
The (start|commit|rollback)Transaction methods are there because you definitely don't want your listener to have any knowledge of your persistance mechanism. You probably don't want modelCFC to know anything about it either, instead deferring yet again to an even lower level persistanceCFC, so modelCFC can just concentrate on business rules. However, you need to be able to control the transaction at the listener level. Those methods provide that control, which keeping the actual implementation fully encapsulated. Your implementation is just going to be a single CFTRANSACTION tag for each method, but the idea is that if you later switch to another persistance mechanism (say, XML files) you don't have to change anything except the persistance object (to use CFLOCK and some temp XML files). That way you listeners and modelCFC (which contains business rules) don't have to care about the persistance mechanism in any capacity, other than the interface for dealing with the object that encapsulates it. That benefit probably seems pretty small to you, but even if you're locked into a single DBMS (very likely) you can still give that persistanceCFC to your DBA if/when you get one, and he can do whatever he needs, without affecting the rest of your code. For example, I think creating stored procs is a pain in the ass, and I don't like to do for simple stuff. But it needs to be done for performance reasons. I can develop my app, building the CFC with just CFQUERY tags (easy to change), and then when it's done, pass that over to a SQL guru to have him write me some stored procs and change the CFC to use them. Because of the encapsulation, the rest of my app doesn't need to change at all. cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Justin Balog > Sent: Tuesday, October 14, 2003 10:21 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Mach-ii Managing Transactions > > > Barney, > > How do you see the modelCFC.startTransAction(), commitTransaction(), and > rollbackTransaction() behaving? > > It looks good, were you in Law Enforcement before programming =) > > -----Original Message----- > From: Barney Boisvert [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2003 10:50 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Mach-ii Managing Transactions > > > All the events are under the same request, so yes, you can > techincally pass > all kinds of stuff down the event tree. However, doing that makes for > tightly coupled events, which, at that point, may as well be > combined into a > single event. The benefit of an II architecture is that you don't know > what's going to be called next, and you don't know what has been called > before, so the link between successive events should be limited to only > eventArgs that are passed with the announceEvent method, or in the > event-mapping tag. That seems like a undesirable trait (as you > are finding > out, and I had to learn the hard way as well), but it's a good thing, > because it encapsulates the events into self-contained packages that can > more easiliy be reused. > > I'd say that clicking the 'default' button initiates an action on > the server > that does all those things you list, and then announces another event that > displays a confirmation to the user. So for that entire request, you only > have two events being fired. Within the first action, there is > probably two > listeners. One to generate the PDF and print it, and another > that does the > rest of it (under a method named defaultTrafficTicket() or something). > Within that method, you'd have calls to a bunch of other backend > CFCs to do > the various sub-tasks, the first of which would be starting a transaction, > and the final one is ending the transaction. > > Here's some EXTREMELY rough, over-simplified psuedo-code. I don't know > exactly what you're setup is, but this is the route I'd start down. I > didn't supply code for modelCFC.cfc, Ticket.cfc or Warrant.cfc, but you > should be able to follow the algorithm. > > mach-ii.xml: > ------------ > <event name="defaultTicket"> > <listener name="PrinterListener" method="printTrafficTicket" /> > <listener name="TicketListener" method="defaultTrafficTicket" /> > </event> > > TicketListener.cfc: > ------------------- > method defaultTrafficTicket(id) { > modelCFC.startTransaction(); > try { > ticket = modelCFC.getTicket(id); > ticket.default(); // this would add the fine and audit action > if (ticket.doesDefaultRequireWarrant()) { > warrant = modelCFC.createWarrant(); > warrant.setInitialOffence(ticket); > } > ticket.persist(); > modelCFC.sendTicketToDMV(ticket); // this would send an > create the audit > action > modelCFC.commitTransaction(); > } catch (any e) { > modelCFC.rollbackTransaction(); > } > } > > cheers, > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Justin Balog > > Sent: Tuesday, October 14, 2003 9:25 AM > > 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] > ---------------------------------------------------------- > 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]
