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 - 10:53:04 EST