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]
