RE: How to retrieve the PK from the anArtist bean?

From: Fan, Bill (AP - Australia) ("Fan,)
Date: Mon Dec 30 2002 - 21:46:58 EST

  • Next message: Dirk Olmes: "Re: How to retrieve the PK from the anArtist bean?"

    Hi Dirk & Martin,

    Very cool idea!! Thanks very much for that!

    > Sure, while a unique identifier for a (CayenneData)Object already exist,
    why
    > not use it?
    How do you use this unique identifier(i.e the hashCode() value) to retrieve
    the Artist object from the data context?

    What I'm trying to do is exactly the same as Martin does - edit(hence to
    update) the artist record. However, I'm trying to avoid to get to the PK
    value as you suggested, I passed the anArtist.getObjectId().hashCode()
    instead. In the artistBrowsePage.jsp, I added a hyperlink like this,

    <a
    href="editArtist.do?objectIdHashCode=<%=anArtist.getObjectId().hashCode()%>"
    >edit artist</a>

    When this link is clicked, the control will be passed to the
    EditArtistAction.java(a new class I'm playing with). In this class, how do I
    use the objectIdHashCode value passed from the reuqest object to retrieve
    the corresponding Artist object?

    Thanks for help;-)
    Bill

    -----Original Message-----
    From: martin ruff [mailto:mruf..imeon.ch]
    Sent: Tuesday, December 31, 2002 1:54 AM
    To: Dirk Olmes; cayenne-use..bjectstyle.org
    Subject: Re: How to retrieve the PK from the anArtist bean?

    Hi Dirk,

    Dirk Olmes wrote:
    >>the EmployeeBO is just a wrapper for the Employees object (the
    >>generated extended CayenneDataObject), its attribute theEmployee
    >>is of type CayenneDataObject ID is the PK which I get with
    >>getObjectId().getIdSnapshot() ..., which I pass as parameter to
    >>the employeeEdit page.
    >
    >
    > If you wrap the CayenneDataObject anyway, why do you (ab)use its primary
    key
    > for display purposes? The EmployeeBO should be able to manage its own id
    for
    > display purposes (and nothing else).
    >
    > Sidenote: other web frameworks (e.g. Tapestry) manage the whole
    > object-to-identifier mapping for the web layer themselves. There's no need
    for manual
    > user intervention.
    thnaks for the tip, I'll have a look at Tapestry

    >
    >>The problem now is: On the employeeEdit page I have to identify
    >>the employee the user selected in the list, therefor I submit
    >>it's ID (the PK) to get the appropriate selected user on the
    >>employeeEdit page.
    >
    >
    > Again, this is only for the web layer, right? Why abuse the database
    > artefact for such purposes? Couldn't the identifier in the web layer be
    e.g. the
    > hashCode() of the object you're giving out?
    Thanks, this is a very good idea, I'm gonna change my code accordingly
    (already changed some)
    so I do not have to expose the PK concept which should be
    "cayenne-visible" only, so I get a much cleaner design

    >
    >>In a swing application I would show the user a list of Employees
    >>objects (of type CayenneDataObject). when the user selects an
    >>employee I would pass the Employees object to the employeeEdit
    >>page, so I would not have to access its PK. I would ALLWAYS work
    >>with objects.
    >
    >
    > See, this kind of UI layer does not impose any restrictions on your object
    > model.....
    >
    >
    >>But in a web app, I cannot put Employees objects in the employees
    >>list page (jsp page) and pass a Employees object as request
    >>parameter to the employeeEdit page. So in this web-context what
    >>would be the right cayenne way to solve the problem described
    >>WITHOUT accessing the employees PK?
    >
    >
    > ... whereas JSP requires for some kind of id. Note that technically this
    has
    > absolutely no relationship to the primary key of the CayenneDataObject.
    >
    > Sure, while a unique identifier for a (CayenneData)Object already exist,
    why
    > not use it? But make sure that you don't get bitten in the long run by
    this.
    > I'm talking about separating model from view in this case. What happens if
    > you discover lateron that you'll promote another column in your DB table
    to a
    > PK column so you have a compound primary key (Admitted, this example is
    > somewhat constructed ....)? You'd not only have to change your object
    model but
    > also the view presenting those objects. This is not what you want.
    Yep you're right, with the hashCode() I will have a clean sepearation
    between view and model. I'll make myself a new leyer which maps the code
    from hashCode back to an (CayenneData)Object, which will be transparent
    for the view and the model, with this technique I can always work on
    object level, as I would in a swing app
    thanks again for the tip and a happy new 2003 !!!
    martin

    > Just my 0.01 EUR,
    >
    > -dirk
    >



    This archive was generated by hypermail 2.0.0 : Mon Dec 30 2002 - 20:47:19 EST