cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Wiesmann" <>
Subject Re: DataView status
Date Mon, 30 Oct 2006 16:17:42 GMT
Hi Malcolm

> With DV you can have different views across the same object entities
> to support these different requirements.  With a straight annotation
> based approach I can't see how it would support these scenarios.

There is another scenario. List and detail views where you use the same
DataContext to render a list of DataObjects and to render one single
DataObject which can then be edited. In the list you normally show
different fields (or not the same group or something) like in the detail
view. The detail view mostly contains more fields than the list view.

> Extra fields which could be added the the ObjFieldView include:
> * sortable - UI hint for columns
> * width - UI field / column width hint

Good ideas.

Foreignkey reference information is something which we also miss. I would
like to be able to add the name of a DataView to the foreign key
reference: When showing a list of DataObjects and one of the fields is a
reference to another type of DataObjects, we currently have the
functionality that we add a button besides the corresponding field in the
UI. Clicking the button will open up a modal search dialog. While it is
clear what type of DataObject we want to search for, we need another
DataView to render a list of DataObjects.

> * tooltip - for field help

Good idea (we already do have the captions there). But there should be
some multi language support. Or some hook to where you could hook up some
piece of code which does the translation.

Adding a help hook would be another idea.

Yet another idea would be to define the edit states. Which means: Can the
user edit data within this DataView or is it for read only?

> I haven't figured out how a list of values (for a select / ComboBox)
> is represented in the DV design.

This looked a little bit tricky to me. Afaik the list renders a combobox.
But that is not a good solution. Especially when these foreignkey
constraints can contain huge lists of records. We solve this with modal
searches, see above for details.

Perhaps we should elaborate on the different usage strategies/techniques
of DV.


View raw message