Yeah that could be done but conditions exist to avoid the additional overhead of executing every possible ECA service.
The quality of the pattern aside, my concern is more about the confusion to developers. To randomly declare a bad practice in the example app for something that is heavily used throughout the system would leave me scratching my head as to how exactly I'm supposed to trigger a SECA on a specific status change. Regards Scott On 24/10/2012, at 11:09 AM, Adrian Crum wrote: > It could be fixed by removing the ECA condition and have the > createExampleStatus service do a better job of checking status changes. > > I agree the pattern is used heavily throughout the codebase, but that doesn't > make it a good pattern. > > -Adrian > > On 10/23/2012 10:23 PM, Scott Gray wrote: >> Hi Adrian, >> >> This type of pattern is pretty heavily used throughout the codebase isn't >> it? While updating a status history table might not be the best use of it, >> it does still serve as an example of that pattern. Couldn't it be fixed by >> including an is-not-empty condition? >> >> Thanks >> Scott >> >> On 24/10/2012, at 12:40 AM, adri...@apache.org wrote: >> >>> Author: adrianc >>> Date: Tue Oct 23 11:40:51 2012 >>> New Revision: 1401254 >>> >>> URL: http://svn.apache.org/viewvc?rev=1401254&view=rev >>> Log: >>> Commented out a bad ECA in the Example component that was causing >>> exceptions to be thrown in the updateExample service. >>> >>> Modified: >>> ofbiz/trunk/specialpurpose/example/servicedef/secas.xml >>> >>> Modified: ofbiz/trunk/specialpurpose/example/servicedef/secas.xml >>> URL: >>> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/example/servicedef/secas.xml?rev=1401254&r1=1401253&r2=1401254&view=diff >>> ============================================================================== >>> --- ofbiz/trunk/specialpurpose/example/servicedef/secas.xml (original) >>> +++ ofbiz/trunk/specialpurpose/example/servicedef/secas.xml Tue Oct 23 >>> 11:40:51 2012 >>> @@ -23,8 +23,13 @@ under the License. >>> <eca service="createExample" event="return"> >>> <action service="createExampleStatus" mode="sync"/> >>> </eca> >>> + <!-- FIXME: This ECA assumes the updateExample service was called with >>> a statusId parameter. >>> + The ECAs in this file demonstrate a bad design pattern. The >>> action services should be >>> + invoked within the called service, not invoked by ECAs. --> >>> + <!-- >>> <eca service="updateExample" event="return"> >>> <condition-field field-name="statusId" operator="not-equals" >>> to-field-name="oldStatusId"/> >>> <action service="createExampleStatus" mode="sync"/> >>> </eca> >>> + --> >>> </service-eca> >>> >>> >
