> 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.
> 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?
> 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.
Just my 0.01 EUR,
-dirk
-- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
This archive was generated by hypermail 2.0.0 : Mon Dec 30 2002 - 08:31:16 EST