If you needed a message or any other values set into the event-arg, you can do that from inside the listener itself. The only problem with that approach is that the name of those event-args would likely be hard-coded, instead of specified in the XML, though it still could be done. It would just result in some messier xml.
On Apr 30, 8:57 am, Joe H <[email protected]> wrote: > Brian, > > Can you send me an example of what such a filter would look like? I'm > usually an advocate of putting validation logic in the model, but I > don't see how that would allow us to implement a simple pass/fail > filter. The approach that we've used in the past is to stuff the form > data into the proper bean, then have the bean validate itself. > However, this doesn't avoid validation that would need to involve the > service, like performing duplicate checks, constraints on > relationships, etc. Since possibly both the service to be used and the > methods to call on that service would differ, it seems that you'd need > to have specific logic in the filter that calls the appropriate > service(s) and method(s), meaning you couldn't get away with a generic > filter. > > Even looking at the validation needs on a create vs. edit form, the > validation logic would differ slightly. For example, suppose I have an > object with the following properties: > -ID > -Name > -Description > ...and say that I want the name to be unique. Now, on a create event, > I'd want to verify that an object with the same name does not already > exist. However, on an edit event, I'd want to verify that _another_ > object with the same name does not already exist, meaning I would > either need to check for a change in the name or check for an object > matching the updated name that does not have the same ID as the object > being updated. This is a simple example, but even here it's not > trivial to write generic validation logic to handle both cases, at > least not quickly or readably, IMHO. > > -- > You received this message because you are subscribed to Mach-II for CFML list. > 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 > athttp://groups.google.com/group/mach-ii-for-coldfusion?hl=en > > ***New URLs as of April 29th, 2010*** > SVN:http://svn.mach-ii.com/machii/ > Wiki / Documentation / Tickets:http://trac.mach-ii.com/machii/ -- You received this message because you are subscribed to Mach-II for CFML list. 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/mach-ii-for-coldfusion?hl=en ***New URLs as of April 29th, 2010*** SVN: http://svn.mach-ii.com/machii/ Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
