Either that, or fire a beforeCacheSynchronise() event? Mark
On Fri, Aug 14, 2009 at 1:17 AM, Denver <[email protected]> wrote: > > Everyone, I've done a lot of experimentation, and with the current > implementation of Transfer, I am *not* going to be able to use clone() > and make changes to a cloned object, and then compare those changes in > a beforeEventHandler in order to derive history. > This is because the update() method in transfer.com.Transfer *first* > synchronizes an object with the cache, and *then* it fires the > beforeEventHandler. This occurs on lines 245-250 in transfer/com/ > Transfer.cfc. > > I am wondering if it could be good to move line 250 above line 245, > and change the line we're moving to run on arguments.transfer instead > of on the cachedObject. Would there be problems with doing this? One > large benefit would be that anyone handling the BeforeUpdate event > would be able to find out what exactly has changed, instead of just > knowing that "something" changed. > > Here is what I'm proposing/wondering about: > > Before: > <code> > if(arguments.transfer.getIsDirty()) > { > cachedObject = > getCacheManager().synchronise(arguments.transfer); > > //queue it regardless, in case something goes wrong in the > update > getCacheManager().appendTransactionQueue(cachedObject); > > getEventManager().fireBeforeUpdateEvent(cachedObject); > > <!--- ... ---> > } > </code> > > After: > <code> > if(arguments.transfer.getIsDirty()) > { > getEventManager().fireBeforeUpdateEvent(arguments.transfer); > > cachedObject = > getCacheManager().synchronise(arguments.transfer); > > //queue it regardless, in case something goes wrong in the > update > getCacheManager().appendTransactionQueue(cachedObject); > > <!--- ... ---> > } > </code> > > > What are your thoughts? > > -Denver > > On Aug 6, 1:15 pm, Matt Quackenbush <[email protected]> wrote: > > Elliott, > > > > To be clear, I only said that clone() should be used when editing an > > object. Consider this scenario... > > > > Step 1: User submits form with data to edit/update an object > > > > Step 2: Grab object from Transfer and populate with new data > > > > Step 3: Validation of new data fails > > > > Step 4: Skip the save, send user back to form with validation error > messages > > > > Because we did not use clone() in Step 2 above, you now have bad data in > > your Transfer cache. > > > > I would be more than happy to read about how others handle this issue, > but > > from where I am sitting, the only choices I see to deal with this > scenario > > are: > > > > 1) Use clone() before populating the object with new data > > > > 2) Create a completely different object and validate against it (and then > > use it to populate the TO if valid) > > > > 3) Perform all validation without relying on a business object at all > > > > #1 and #2 seem to be essentially the same to me, so I go with #1. > Otherwise > > we get into a 2-for-1 object map scenario. > > > > #3 was always a complete PITA for me prior to being introduced to any OO > > concepts. Having an intelligent object that knows how to validate itself > > has been a godsend for me. So #3 does not really grab my attention much. > > > > Do you have other suggestions? I am **very** interested in learning how > > this is handled by people who have _much_ more experience than I do. :-) > > > -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-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/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
