Polite warning: long message.
> For me the double-click only replaced the relationships, but left the
> original (clicked) object unchanged.
*Ahem* misplaced an else. Take my word for it for now: double-clicking
cycles through the clicked on object as well as all child objects.
> Still I'd love us to come up with better representations for (1) and
> (2). One way is to think of a collection of objects (be it the initial
> fetch result, or a to-many relationship) as a graph node, same as
> individual object nodes. This would mean a "collection shape" should
> be displayed on screen, with an arrow from the owning object, and
> arrows to the "opened" objects. Clicking on a collection may open a
> dropdown list of contained objects, so the user can select just one
> she cares about at the moment.
The collection is already there (you just can't see it because of the
above bug). I like the idea of moving a particular record out of the
collection into its own node, that would allow more than one record from
the same collection to be viewed at once. I guess I'll add a little '+'
button to put the record in its own node (or maybe drag and drop later
on), and a different connection type to represent 'belongs to'. That
opens up a lot more flexibility in viewing records: collection with
selected records of interest clustered around it, each with their own
relationships.
I also like the idea of a drop down. The most feasible place for it
would be in the right-click menu (which at the moment has delete, undo
and redo) as a sub-menu.
>
> If we solve the collection representation issue in one way or the
> other, it will become possible to implement unique object display as
> well. And object uniquing is certainly something I would like to
> preserve. (BTW, in Cayenne internally this is one of the central
> concepts).
>
I'm not sure what you mean by uniquing in this context. Checking to see
if an object (say, a given Artist) is anywhere in the diagram isn't
suitable. Consider Dept and Employee tables, where Dept has n employees
and 1 boss, all drawn from the Employee table. When I expand the
employees relationship, I get a collection of Employee objects including
the boss. When I expand the boss relationship, I don't want to point to
the same visual part (the collection of Employees) even though the boss
is in it.
The only alternative I can see to the present setup (which just expands
any relationship the user asks to see expanded, but won't expand the
same relationship twice) is to refuse to expand relationships which have
already been expanded from the other end (ie if the Dept -> Employee
relationship has already been expanded, clicking on the Dept
relationship in the employee table does nothing). But there is no reason
to refuse this: if that's what the user wants to see, why not let them?
>>> 3. When no results are returned from the query (or relationship), a
>>> square with "null" in it is displayed.
>> Yes. A more detailed message suggested (or other functionality)?
>
> It depends on how we handle the issues above. I think a collection
> shape showing a count of zero would work. For null to-one
> relationships maybe show "null" somewhere in the owning object (just
> like we show simple property values), or make clickable (non-null) and
> non-clickable (null) relationships visually different. Somehow showing
> an arrow connecting to null seems wrong.
>
Making "clickable (non-null) and non-clickable (null) relationships
visually different" is problematic because 1) I would have to check
every relationship in advance to see if it returns null and 2) it may
return null for one record in a collection but not others, meaning said
checking would have to be carried out every time the user moves to a new
record.
I show a null in the node so that the user can see that the relationship
has been expanded but is null for the current record. If the current
record is changed, the null node is updated with the data for the new
record. I could change the colour for a null record to make it clearer,
and I need to stop it being so small, but I think the mechanism is sound.
Also, I forgot to point out before: take a look at the Eclipse
Properties view (Window->Show View->Other...->Basic->Properties) when a
node is selected - it allows editing of values and shows the number of
records in the collection.
marcel
This archive was generated by hypermail 2.0.0 : Wed Jul 12 2006 - 23:31:54 EDT