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. :-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
