Re: Setting a user stamp on objects

From: Derek Rendall (cayenn..sure.com)
Date: Mon Dec 06 2004 - 16:51:01 EST

  • Next message: Andrus Adamchik: "Re: Setting a user stamp on objects"

    > Hi Derek,
    >
    > I think all your Ideas are not the right way ...

    I'm not that happy with them myself :-)

    >
    > I would prefer do use my own DataObject-Class derived from
    > CayenneDataObject
    > for all my Business-Objects.
    > There you can override the validate* methods, which are called when
    > an DataObject is commited by the DataContext ...
    >

    I have a base class defined.

    > So you have one class to handle the user-information for
    > all your DataObjects.

    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

    > Have a lot of fun ...
    > --- Juergen ----
    >
    >
    > "Derek Rendall" <cayenn..sure.com> schrieb am 05.12.04 23:03:09:
    >>
    >> Hi
    >>
    >> I have a database where each table has a field that stores the user who
    >> last
    >> updated the record. In our current apps we pass around an object that
    >> contains the user information and set the field in the objects as part of
    >> the save process. I would prefer it if I could hide and aoutomate this. I
    >> can see several possible ways of handling this, but am not sure which is
    >> the
    >> most appropriate.
    >>
    >> (1) Create a subclass of DataContext which can store User Info. I could
    >> create this via my own factory method, pass it the user details. Then in
    >> a
    >> superclass of all my objects I could override validateForSave and grab
    >> the
    >> user information from my data context and set it as appropriate. After
    >> having a look at DataContext I'm not sure that this is a "stable"
    >> approach
    >> (for one thing, the EventSubject instances are final and use the
    >> DataContext
    >> class). Adding a map of "constant" information to the Data Context might
    >> be
    >> a nice addition?
    >>
    >> (2) I would love it if the Delegate helped me out, but it doesnt seem to
    >> have an entry that matches where I want to "interrupt" the process.
    >>
    >> (3) Using the DataContext events - WILL_COMMIT in particular. However,
    >> the
    >> quote from an entry in the lists "Re: EventSubjects" dated Wed Jul 21
    >> 2004 - 16:13:34 has the following comment by Andrus that makes me nervous
    >> that this approach is a "second class citizen":
    >>
    >> " Another place is DataContext events. I wasn't a big fan of it when this
    >> was originally submitted, now and seems more useful to me (still I am
    >> looking to redesign this some more in the future :-))... "
    >>
    >> Any advice or clarification would be most appreciated.
    >>
    >> Thanks
    >>
    >> Derek
    >>



    This archive was generated by hypermail 2.0.0 : Mon Dec 06 2004 - 16:51:07 EST