Re: [JIRA] Closed: (CAY-593) rop-browser update

[Andrus Adamchik <an...@objectstyle.org>]

[sending to dev list]

Ok, here are some things that I noticed:

1. if there is more than one object returned from fetch or a  
relationship, still only one object is displayed (not sure if this is  
simply a layout issue?)

2. Object "uniquing" is broken. I.e. if I start from an Artist  
object, navigate to a Painting, and then to Painting's Artist, I get  
two artists displayed for the same object.

3. When no results are returned from the query (or relationship), a  
square with "null" in it is displayed.

Andrus


On Jul 12, 2006, at 3:13 AM, Marcel wrote:

>
> Great news!
>
> Please nit pick, you might pick different nits to this nitpicker.
>
> The basic functionality is there, but clearly there is still plenty  
> to do.
>
> At the moment I am working on automatic layout. The other things on  
> the list are:
>
> - being able to add and remove records
> - XMPP (I tried to start this before my break, but ran into major  
> headaches - expect some questions)
> - load/save (so that a view on a query can be restored)
> - general appearance improvement
>
> Any other features come to mind?
>
> Marcel
>
> Andrus Adamchik (JIRA) wrote:
>>      [ http://issues.apache.org/cayenne/browse/CAY-593?page=all ]
>>      Andrus Adamchik closed CAY-593:
>> -------------------------------
>>
>>     Resolution: Fixed
>>
>> Excellent!! The second patch worked like a charm (I just committed  
>> it). I can run the rop-browser from eclipse, fetch the data and  
>> navigate relationships. There are certainly a number of glitches,  
>> but pointing to those would be nitpicking at this point. Looking  
>> forward for more patches :-)
>>
>>
>>> rop-browser update
>>> ------------------
>>>
>>>          Key: CAY-593
>>>          URL: http://issues.apache.org/cayenne/browse/CAY-593
>>>      Project: Cayenne
>>>         Type: Improvement
>>>
>>
>>
>>>     Versions: SUMMER OF CODE 2006
>>>     Reporter: Marcel
>>>     Assignee: Andrus Adamchik
>>>  Attachments: patch.txt, patch.v2.txt
>>>
>>> Latest rop-browser code. The patch file attached was generated  
>>> using the command:
>>> diff -r -u rop-browser incubator/rop-browser > patch.txt
>>> I've built and run this from scratch - checked out a clean copy  
>>> from SVN - without problem so the dependency problems should be  
>>> gone.
>>>
>>
>>
>

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Andrus Adamchik <an...@objectstyle.org>]

Yes, exactly.

On Jul 13, 2006, at 12:09 AM, Marcel wrote:

>
> I think I see what you mean: we would automatically pull the record  
> out of the collection and display it separately. It could end up  
> being part of more than one collection. That would give a much more  
> sophisticated view of the data. Good idea. I was stuck in "one  
> record visible per collection" mode.
>
> Andrus Adamchik wrote:
>> I am going offline for tonight. I'll read the rest of your comment  
>> tomorrow. Let me answer this one though.
>>
>> On Jul 12, 2006, at 11:30 PM, Marcel wrote:
>>
>>> 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.
>>
>> I think it is.
>>
>>> 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.
>>
>> I don't see a problem with this scenario. Collection and its  
>> elements can be made separate things visually (and this is what I  
>> was trying to say in the previous message). I guess I may need to  
>> draw a picture in Photoshop or something to better illustrate what  
>> I'm saying. When you expand the boss relationship you point to  
>> another employee (who is the boss). Employee, not the collection  
>> of employees.
>>
>>> 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).
>>
>> It can do something visual, such as change the color of the  
>> relationship arrow and the outline of the target object selected.
>>
>>> But there is no reason to refuse this: if that's what the user  
>>> wants to see, why not let them?
>>
>> Because it would incorrectly represent the graph. It will show  
>> multiple nodes where there is one. Besides we are not preventing  
>> the user from seeing the node he wants to see. We are just  
>> pointing him to the right place, saying "see, it is already opened".
>>
>> Andrus
>>
>

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Marcel <em...@gmail.com>]

I think I see what you mean: we would automatically pull the record out 
of the collection and display it separately. It could end up being part 
of more than one collection. That would give a much more sophisticated 
view of the data. Good idea. I was stuck in "one record visible per 
collection" mode.

Andrus Adamchik wrote:
> I am going offline for tonight. I'll read the rest of your comment 
> tomorrow. Let me answer this one though.
>
> On Jul 12, 2006, at 11:30 PM, Marcel wrote:
>
>> 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.
>
> I think it is.
>
>> 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.
>
> I don't see a problem with this scenario. Collection and its elements 
> can be made separate things visually (and this is what I was trying to 
> say in the previous message). I guess I may need to draw a picture in 
> Photoshop or something to better illustrate what I'm saying. When you 
> expand the boss relationship you point to another employee (who is the 
> boss). Employee, not the collection of employees.
>
>> 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).
>
> It can do something visual, such as change the color of the 
> relationship arrow and the outline of the target object selected.
>
>> But there is no reason to refuse this: if that's what the user wants 
>> to see, why not let them?
>
> Because it would incorrectly represent the graph. It will show 
> multiple nodes where there is one. Besides we are not preventing the 
> user from seeing the node he wants to see. We are just pointing him to 
> the right place, saying "see, it is already opened".
>
> Andrus
>

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Andrus Adamchik <an...@objectstyle.org>]

I am going offline for tonight. I'll read the rest of your comment  
tomorrow. Let me answer this one though.

On Jul 12, 2006, at 11:30 PM, Marcel wrote:

> 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.

I think it is.

> 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.

I don't see a problem with this scenario. Collection and its elements  
can be made separate things visually (and this is what I was trying  
to say in the previous message). I guess I may need to draw a picture  
in Photoshop or something to better illustrate what I'm saying. When  
you expand the boss relationship you point to another employee (who  
is the boss). Employee, not the collection of employees.

> 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).

It can do something visual, such as change the color of the  
relationship arrow and the outline of the target object selected.

> But there is no reason to refuse this: if that's what the user  
> wants to see, why not let them?

Because it would incorrectly represent the graph. It will show  
multiple nodes where there is one. Besides we are not preventing the  
user from seeing the node he wants to see. We are just pointing him  
to the right place, saying "see, it is already opened".

Andrus

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Marcel <em...@gmail.com>]

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

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Andrus Adamchik <an...@objectstyle.org>]

Hi Marcel,

I posted a screenshot on the website to provide others with a  
reference point:

http://dev.objectstyle.org/~andrus/rop-screen.png


>> 1. if there is more than one object returned from fetch or a  
>> relationship, still only one object is displayed (not sure if this  
>> is simply a layout issue?)
> The interface isn't entirely intuitive - though its reasonably  
> effective - if you double click on an object, it will cycle through  
> the records.

For me the double-click only replaced the relationships, but left the  
original (clicked) object unchanged.

> Single click on a relationship expands the relationship.

This worked.


>> 2. Object "uniquing" is broken. I.e. if I start from an Artist  
>> object, navigate to a Painting, and then to Painting's Artist, I  
>> get two artists displayed for the same object.
> The uniquing works in a different way - the objects on the screen  
> are both collections of Artists. A query might return 3 Artists  
> (all displayed in the same cycleable node), one of whom has 2  
> Paintings. When you navigate to a Painting's Artist, the new object  
> displayed is a collection of only one Artist, rather than 3, so it  
> is different.
>
> I figure that if you choose to expand a relationship onwards like  
> that, you must have a reason to want to see it in another node, so  
> I haven't stopped it happening.

I see...

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.

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).

>> 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.

Does it make sense?

Andrus

Re: [JIRA] Closed: (CAY-593) rop-browser update

[Marcel <em...@gmail.com>]

> 1. if there is more than one object returned from fetch or a 
> relationship, still only one object is displayed (not sure if this is 
> simply a layout issue?)
The interface isn't entirely intuitive - though its reasonably effective 
- if you double click on an object, it will cycle through the records. 
Single click on a relationship expands the relationship.
>
> 2. Object "uniquing" is broken. I.e. if I start from an Artist object, 
> navigate to a Painting, and then to Painting's Artist, I get two 
> artists displayed for the same object.
The uniquing works in a different way - the objects on the screen are 
both collections of Artists. A query might return 3 Artists (all 
displayed in the same cycleable node), one of whom has 2 Paintings. When 
you navigate to a Painting's Artist, the new object displayed is a 
collection of only one Artist, rather than 3, so it is different.

I figure that if you choose to expand a relationship onwards like that, 
you must have a reason to want to see it in another node, so I haven't 
stopped it happening.
>
> 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)?

Marcel
>
> Andrus
>
>
> On Jul 12, 2006, at 3:13 AM, Marcel wrote:
>
>>
>> Great news!
>>
>> Please nit pick, you might pick different nits to this nitpicker.
>>
>> The basic functionality is there, but clearly there is still plenty 
>> to do.
>>
>> At the moment I am working on automatic layout. The other things on 
>> the list are:
>>
>> - being able to add and remove records
>> - XMPP (I tried to start this before my break, but ran into major 
>> headaches - expect some questions)
>> - load/save (so that a view on a query can be restored)
>> - general appearance improvement
>>
>> Any other features come to mind?
>>
>> Marcel
>>
>> Andrus Adamchik (JIRA) wrote:
>>>      [ http://issues.apache.org/cayenne/browse/CAY-593?page=all ]
>>>      Andrus Adamchik closed CAY-593:
>>> -------------------------------
>>>
>>>     Resolution: Fixed
>>>
>>> Excellent!! The second patch worked like a charm (I just committed 
>>> it). I can run the rop-browser from eclipse, fetch the data and 
>>> navigate relationships. There are certainly a number of glitches, 
>>> but pointing to those would be nitpicking at this point. Looking 
>>> forward for more patches :-)
>>>
>>>
>>>> rop-browser update
>>>> ------------------
>>>>
>>>>          Key: CAY-593
>>>>          URL: http://issues.apache.org/cayenne/browse/CAY-593
>>>>      Project: Cayenne
>>>>         Type: Improvement
>>>>
>>>
>>>
>>>>     Versions: SUMMER OF CODE 2006
>>>>     Reporter: Marcel
>>>>     Assignee: Andrus Adamchik
>>>>  Attachments: patch.txt, patch.v2.txt
>>>>
>>>> Latest rop-browser code. The patch file attached was generated 
>>>> using the command:
>>>> diff -r -u rop-browser incubator/rop-browser > patch.txt
>>>> I've built and run this from scratch - checked out a clean copy 
>>>> from SVN - without problem so the dependency problems should be gone.
>>>>
>>>
>>>
>>
>
>