That sounds right to me. I was thinking that having the consume() method handle both workitems and cancelitems is a bit weird anyway. Handling a workitem versus a cancleitem are really two different behaviours, so conceptually it makes sense to put them in two different methods. Also, checking whether the participant responds to a cancel() method is also a good Ruby-esque way to make this happen ( i.e. duck typing)...
On Sep 18, 7:23 pm, "John Mettraux" <[EMAIL PROTECTED]> wrote: > On 9/18/07, John Mettraux <[EMAIL PROTECTED]> wrote: > > > On 9/18/07, Matt Zukowski <[EMAIL PROTECTED]> wrote: > > > > ... but even if this is the solution, what about off-the-shelf > > > participants? For example, I'm getting errors when trying to cancel a > > > process that uses the built-in MailParticipant. What can I do to > > > ensure that this participant can handle the CancelItem (other than > > > wrapping it inside a custom participant)? > > Hi Matt, > > I have been thinking about this. > > Currently the engine makes sure that participant that don't have a > cancel() method get the CancelItem anyway via their consume() method. > > What if we simply did not send CancelItem instances to participants > that don't have a cancel() method ? > > It would keep code shorter, no need to add a "return if > wi.is_a?(CancelItem)", and it's quite easy to open a class and add a > cancel method afterwards. > > Wdyt ? > > -- > John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" 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/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
