Re: Identifying changed fields
Re: Identifying changed fields
- Subject: Re: Identifying changed fields
- From: Chuck Hill <email@hidden>
- Date: Mon, 15 Aug 2005 17:18:27 -0700
Yes, you are correct. I edited it before posting so that I could be
used anywhere. The real method in our EO superclass looks more like
public NSDictionary changedProperties() {
return changesFromSnapshot(editingContext
().committedSnapshotForObject(this));
}
On Aug 15, 2005, at 5:15 PM, Jerry W. Walker wrote:
Am I missing something?
That looks like a wholly self contained method that could be put
practically anywhere, since it's returned valued seems to only
depend on the EO argument provided (and EOF, of course).
Regards,
Jerry
On Aug 15, 2005, at 4:36 PM, Chuck Hill wrote:
That is a method that I put in our subclass of EOGenericRecord.
That subclass is used in generated Java files. Yes, we use
EOGenerator to do that.
Chuck
On Aug 15, 2005, at 1:17 PM, Arturo Perez wrote:
Hi Chuck,
Is that something to be added to each EOCustomObject?
Chuck Hill wrote:
public NSDictionary changedProperties(EOEnterpriseObject eo) {
NSDictionary commitedValues = eo.editingContext
().committedSnapshotForObject(eo);
return eo.changesFromSnapshot(commitedValues);
}
On Aug 15, 2005, at 10:12 AM, Karl wrote:
Its pretty easy to do what you want to do. However,
subclassing the EC is not really required.
An EO has access to its own various snapshots. You should
probably implement this at that level either by overriding the
willChange() method on the EOGenericRecord or EOCustomObject.
Take a snapshot at this point and use it later with
changeFromSnapShot(). Pass the results to an auditing method
in your Application.
Karl
On 15-Aug-05, at 1:04 PM, Rick Innis wrote:
I have a request from a client to identify which fields have
been changed when a user updates information in a WebObjects
application. For the moment I've placated them by saying I
can at least tell them which records changed, but I'd like to
do better if I can.
Looking at the WO APIs, it seems to me that subclassing
EOEditingContext might be the way to go; I could then
override objectWillChange to compare the current values in
the object with those returned by committedSnapshortForObject
and keep track of the values that have changed.
Providing an implementation of EOObserving to do this might
be another approach, but then I'd have the overhead of
identifying every object I wanted to track and ensuring it
was properly registered with the observer, which seems like a
lot of extra overhead that EOEditingContext already handles
Does this make sense, am I barking up the worng tree, or is
there a better way to do this?
--Rick.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
% 40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects
developers who want to increase their overall knowledge of
WebObjects, or those who are trying to solve specific application
development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40codefab.com
This email sent to email@hidden
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden