Yeah, that's a pretty common situation when you have to populate some
DataObject properties with external data (i.e. data not available within
DataObject itself) in certain points of the object lifecycle. I think
having a subclass of DataContext is entirely reasonable.
Another technique (I am mentioning it here as a possibility, I never use
it myself) is to bind objects carrying such information to a current
execution thread, kind of like we do for ThreadLocal DataContexts.
Re: "WILL_COMMIT". I guess in the meantime we need to fix that and fire it
prior to validation (could someone please open an issue in Jira?) On the
long run we need to think of a big picture for DataObject lifecycle and
come up with some consistent design. Expanding a delegate maybe a good
solution. It will be more simple and efficient than to send events... And
if events are needed, a delegate can post them in a more customizable way.
Andrus
> Thats what I'm aiming for. I had started using the validate methods, but
> my problem then is that I do not have direct access to who the logged
> in user is. I want a place that I can store this and access it later in
> the validate methods. The data context is a perfect fit for me (created
> on a per user basis), but I don't think I should be subclassing it to
> add my user info.
>
> I tried using the WILL_COMMIT event, but this cuts in AFTER the call to
> validateForSave, so my "required" user stamp field fails the validation
> for new objects, thus the event is never sent. Fair enough.
>
> If there was a delegate that I could set up for each user session that
> could intercept immediately before the validate methods were called,
> then I could use it to grab the list of modified and new objects and
> set the user stamps appropriately. Unfortunately, the
> DataContextDelegate does not cover this situation (from what I read of
> the docs).
>
> So, as we have added some other custom behaviour to Cayenne, I have
> added a map to the DataContext where I can store my "globals" such as
> the
> logged in user. I then use the validate methods in my ommon superclass
> to set the necessary fields (and to initiate the audit trail as well).
> Its dirty, but quick :-). BTW: I would be grateful if anyone could tell
> me if subclassing DataContext is a valid thing to do (I'd rather do
> that than add more changes to our copy of the core code).
>
> Thanks
>
> Derek
This archive was generated by hypermail 2.0.0 : Mon Dec 06 2004 - 17:12:12 EST