You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2008/11/08 20:32:53 UTC
CAY-1077
On Nov 8, 2008, at 8:52 PM, Andrey Razumovsky wrote:
> About M5, I'm still not sure what should we do with CAY-1077.
> Switching
> between single and double click is a minute work and I'd prefer we
> close it
> and release M5 as fast as possible.
Sorry, I kept postponing replying to this. Let me give it a shot
now... I stand by my earlier assessment - the browser has to expand on
a single click... looking at the comment in Jira by Kevin, "the
behavior of the column selector should be the same for the
relationship dialog and the prefetch dialog.", I think I am totally in
favor of following this approach. Here is what it means IMO:
1. The browser should expand on single click
2. "Target" should be a text label, not a dropdown.
3. (??) How do we allow a user to navigate through relationships
without dirtying the selection... It is probably evil to make a single
click selection as it is unclear to the users that they've just
changed something, when they simply wanted to browse around, so let's
make selection a separate step following prefetch/ordering selection
process for queries. So let's add a "select path" button, similar to
"Add Ordering" button for select queries (there won't be a "remove" I
guess, as we are only selecting 1 path). Maybe we can also improve on
the browser - a relationship target entity can be shown as a column
header of the browser panel on the right of the relationship.
Does this sound reasonable?
Andrus
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Andrey,
Thanks for spearheading this. I'll try out the new UI this evening
and give my opinion.
--
Kevin
On Wed, Nov 12, 2008 at 3:29 AM, Andrey Razumovsky
<ra...@gmail.com> wrote:
> I commited the new dialog. Please spend some time trying it out and tell me
> if you like it. Comments about its way of work is in JIRA
>
> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>
>> Fine, but as af as I remember, "Target" should be combobox because 1) There
>>> can be more than one ObjEntity for DbEntity
>>>
>>
>> Good point. Then I guess we need to limit combo choices only to those
>> entities that apply for a given path.
>>
>> 2) User can add new Db Rels in
>>> this dialog by clicking "New to-X relationship" (and target will be what
>>> was
>>> selected in combobox)
>>>
>>
>> I suggest we stop using the combo for targeting (except for the special
>> case above). This creates UI redundancy that can potentially be confusing.
>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>> instead? (Maybe only shown when the dialog is opened from ObjRelationship
>> dialog; and hidden otherwise)?
>>
>> Andrus
>>
>>
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
I'm not against it the suggested change, other than I don't want to
introduce UI confusion. My feeling was that if someone wanted to go
above and beyond, he can modify the XML file directly.
--
Kevin
On Tue, Nov 18, 2008 at 9:21 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> While in reality flattened relationships would never span more than 2 db
> relationships, and loops like that are most likely be limited to something
> like many-to-many, there is no hard rules on what is allowed and what is
> not. So I'd like modeler to encourage best practices, but without limiting
> the possibilities for some crazy people :-)
>
> So maybe instead of "hard culling" we can do a "soft" version. E.g. grey out
> relationships in the browser that are more than 2 steps away from root or
> those that result in a to-one loop?
>
> Andrus
>
>
> On Nov 18, 2008, at 4:14 PM, Kevin Menard wrote:
>>
>> While Cayenne will traverse that path, it's unnecessary. I think
>> allowing such mapping introduces more confusion than anything else and
>> such mapped relationships are normally an error than anything else.
>> As such, I proposed not allowing the relationship path dialog to grow
>> unbounded with such loops.
>>
>> NB: this does not affect the general case of relationship mapping.
>>
>> --
>> Kevin
>>
>>
>>
>> On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>>
>>> Hmm... not that I ever mapped a flattened relationship like that myself,
>>> but
>>> technically this is totally valid:
>>>
>>> ObjRelationship: Painting.peerPaintings
>>>
>>> mapped as
>>>
>>> DbRelationship Path: PAINTING.toArtist.paintings
>>>
>>> Andrus
>>>
>>>
>>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>>
>>>> A -> B -> A is culled (B -> A will not be shown) when relationships are
>>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>>>> paintings)
>>>>
>>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>>>
>>>>>
>>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>>
>>>>> I only was able to play with culling briefly, but it
>>>>>>
>>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>>
>>>>>
>>>>> BTW, what's this about? Looks like I missed something.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>
>>>
>>
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
While in reality flattened relationships would never span more than 2
db relationships, and loops like that are most likely be limited to
something like many-to-many, there is no hard rules on what is allowed
and what is not. So I'd like modeler to encourage best practices, but
without limiting the possibilities for some crazy people :-)
So maybe instead of "hard culling" we can do a "soft" version. E.g.
grey out relationships in the browser that are more than 2 steps away
from root or those that result in a to-one loop?
Andrus
On Nov 18, 2008, at 4:14 PM, Kevin Menard wrote:
> While Cayenne will traverse that path, it's unnecessary. I think
> allowing such mapping introduces more confusion than anything else and
> such mapped relationships are normally an error than anything else.
> As such, I proposed not allowing the relationship path dialog to grow
> unbounded with such loops.
>
> NB: this does not affect the general case of relationship mapping.
>
> --
> Kevin
>
>
>
> On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> Hmm... not that I ever mapped a flattened relationship like that
>> myself, but
>> technically this is totally valid:
>>
>> ObjRelationship: Painting.peerPaintings
>>
>> mapped as
>>
>> DbRelationship Path: PAINTING.toArtist.paintings
>>
>> Andrus
>>
>>
>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>
>>> A -> B -> A is culled (B -> A will not be shown) when
>>> relationships are
>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist
>>> ->
>>> paintings)
>>>
>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>>
>>>>
>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>
>>>> I only was able to play with culling briefly, but it
>>>>>
>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>
>>>>
>>>> BTW, what's this about? Looks like I missed something.
>>>>
>>>> Andrus
>>>>
>>>>
>>
>>
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
While Cayenne will traverse that path, it's unnecessary. I think
allowing such mapping introduces more confusion than anything else and
such mapped relationships are normally an error than anything else.
As such, I proposed not allowing the relationship path dialog to grow
unbounded with such loops.
NB: this does not affect the general case of relationship mapping.
--
Kevin
On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hmm... not that I ever mapped a flattened relationship like that myself, but
> technically this is totally valid:
>
> ObjRelationship: Painting.peerPaintings
>
> mapped as
>
> DbRelationship Path: PAINTING.toArtist.paintings
>
> Andrus
>
>
> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>
>> A -> B -> A is culled (B -> A will not be shown) when relationships are
>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>> paintings)
>>
>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>
>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>
>>> I only was able to play with culling briefly, but it
>>>>
>>>> looks to be cutting down my choices considerably, which is good.
>>>>
>>>
>>> BTW, what's this about? Looks like I missed something.
>>>
>>> Andrus
>>>
>>>
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Cool. If that's what culling is currently about, then I am +1.
So please treat the email that I sent on greying things out as an
optional nice-to-have feature suggestion for the future releases.
Andrus
On Nov 18, 2008, at 4:13 PM, Andrey Razumovsky wrote:
> You're right, B->A must be to-one, not A->B.
>
> ARTIST.paintings.artist is the same object.
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Hmm... not that I ever mapped a flattened relationship like that
>> myself,
>> but technically this is totally valid:
>>
>> ObjRelationship: Painting.peerPaintings
>>
>> mapped as
>>
>> DbRelationship Path: PAINTING.toArtist.paintings
>>
>> Andrus
>>
>>
>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>
>> A -> B -> A is culled (B -> A will not be shown) when relationships
>> are
>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist
>>> ->
>>> paintings)
>>>
>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>>
>>>>
>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>
>>>> I only was able to play with culling briefly, but it
>>>>
>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>
>>>>>
>>>> BTW, what's this about? Looks like I missed something.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
You're right, B->A must be to-one, not A->B.
ARTIST.paintings.artist is the same object.
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
> Hmm... not that I ever mapped a flattened relationship like that myself,
> but technically this is totally valid:
>
> ObjRelationship: Painting.peerPaintings
>
> mapped as
>
> DbRelationship Path: PAINTING.toArtist.paintings
>
> Andrus
>
>
> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>
> A -> B -> A is culled (B -> A will not be shown) when relationships are
>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>> paintings)
>>
>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>>>
>>>
>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>
>>> I only was able to play with culling briefly, but it
>>>
>>>> looks to be cutting down my choices considerably, which is good.
>>>>
>>>>
>>> BTW, what's this about? Looks like I missed something.
>>>
>>> Andrus
>>>
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm... not that I ever mapped a flattened relationship like that
myself, but technically this is totally valid:
ObjRelationship: Painting.peerPaintings
mapped as
DbRelationship Path: PAINTING.toArtist.paintings
Andrus
On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
> A -> B -> A is culled (B -> A will not be shown) when relationships
> are
> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
> paintings)
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>
>> I only was able to play with culling briefly, but it
>>> looks to be cutting down my choices considerably, which is good.
>>>
>>
>> BTW, what's this about? Looks like I missed something.
>>
>> Andrus
>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
A -> B -> A is culled (B -> A will not be shown) when relationships are
reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
paintings)
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>
> I only was able to play with culling briefly, but it
>> looks to be cutting down my choices considerably, which is good.
>>
>
> BTW, what's this about? Looks like I missed something.
>
> Andrus
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
> I only was able to play with culling briefly, but it
> looks to be cutting down my choices considerably, which is good.
BTW, what's this about? Looks like I missed something.
Andrus
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Looks good. I only was able to play with culling briefly, but it
looks to be cutting down my choices considerably, which is good.
I'd say get it out there and let our users play with it. Invariably,
they will find something we missed.
--
Kevin
On Tue, Nov 18, 2008 at 3:58 AM, Andrey Razumovsky
<ra...@gmail.com> wrote:
> Great. Kevin, do you have something to add (I've done culling BTW).
> Otherwise I'll close the issue.
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Very nice.
>>
>> I guess there are still ways to arrange things a little different here and
>> there, but now the functionality is straightforward and there is little room
>> for confusion.
>>
>> One minor note - let's change "Done" button in the "New DbRelationship"
>> dialog to "Continue". Otherwise I think this is finished.
>>
>> Andrus
>>
>>
>> On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
>>
>> I've committed the dialog. Please have a look, and let's get over with it
>>>
>>> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>>
>>>>
>>>> Comments are in-line.
>>>>
>>>>
>>>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>>>> >
>>>> wrote:
>>>>
>>>>> Cool. I very much like the direction. Here is a few notes on the
>>>>> implementation:
>>>>>
>>>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>>>> previous
>>>>> "save", but simply go back in the browser. It is just as easy to use the
>>>>> browser to achieve that. So I suggest we remove those buttons.
>>>>>
>>>>
>>>>
>>>> Are you seeing something different than me? If I modify an existing
>>>> relationship, revert takes me back to that mapped relationship. Clear
>>>> removes all selection.
>>>>
>>>>
>>>> 2. "Save Path" should probably be called "Select", as we are not really
>>>>> saving anything until "Done" is clicked. Also since we only have 1
>>>>> button
>>>>> now, maybe to make things more compact and consistent with other similar
>>>>> interfaces, implement it as a toolbar on top of the browser (see Select
>>>>> Query Ordering tab for an example).
>>>>>
>>>>
>>>>
>>>> +1.
>>>>
>>>>
>>>> 3. DbRelationships. There's a bit of a problem figuring context of the
>>>>>
>>>> new
>>>>
>>>>> relationship. It correctly uses a target of the currently selected
>>>>> DbRelationship path as its source, however its location is disjoint from
>>>>>
>>>> the
>>>>
>>>>> browser so it is not immediately clear. It also clutters the view a bit.
>>>>>
>>>> So
>>>>
>>>>> maybe we can add an extra dialog started with a "new relationship"
>>>>> button
>>>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>>>>>
>>>> allows
>>>>
>>>>> you to select target entity, cardinality (to-one, to-many) and continue
>>>>>
>>>> to
>>>>
>>>>> the joins mapping?
>>>>>
>>>>
>>>>
>>>> +1. The UI is a bit overloaded at the moment. Another option may be
>>>> to implement the dialog as a frame with tab panes.
>>>>
>>>> I'm still not a super huge fan of the constant expansion, but I think
>>>> the improvements made are making it less of an issue.
>>>>
>>>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>>>> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
>>>> I think that would cut down on confusion a bit more.
>>>>
>>>> --
>>>>
>>>> Kevin
>>>>
>>>>
>>
>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Great. Kevin, do you have something to add (I've done culling BTW).
Otherwise I'll close the issue.
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
> Very nice.
>
> I guess there are still ways to arrange things a little different here and
> there, but now the functionality is straightforward and there is little room
> for confusion.
>
> One minor note - let's change "Done" button in the "New DbRelationship"
> dialog to "Continue". Otherwise I think this is finished.
>
> Andrus
>
>
> On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
>
> I've committed the dialog. Please have a look, and let's get over with it
>>
>> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>
>>>
>>> Comments are in-line.
>>>
>>>
>>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>>> >
>>> wrote:
>>>
>>>> Cool. I very much like the direction. Here is a few notes on the
>>>> implementation:
>>>>
>>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>>> previous
>>>> "save", but simply go back in the browser. It is just as easy to use the
>>>> browser to achieve that. So I suggest we remove those buttons.
>>>>
>>>
>>>
>>> Are you seeing something different than me? If I modify an existing
>>> relationship, revert takes me back to that mapped relationship. Clear
>>> removes all selection.
>>>
>>>
>>> 2. "Save Path" should probably be called "Select", as we are not really
>>>> saving anything until "Done" is clicked. Also since we only have 1
>>>> button
>>>> now, maybe to make things more compact and consistent with other similar
>>>> interfaces, implement it as a toolbar on top of the browser (see Select
>>>> Query Ordering tab for an example).
>>>>
>>>
>>>
>>> +1.
>>>
>>>
>>> 3. DbRelationships. There's a bit of a problem figuring context of the
>>>>
>>> new
>>>
>>>> relationship. It correctly uses a target of the currently selected
>>>> DbRelationship path as its source, however its location is disjoint from
>>>>
>>> the
>>>
>>>> browser so it is not immediately clear. It also clutters the view a bit.
>>>>
>>> So
>>>
>>>> maybe we can add an extra dialog started with a "new relationship"
>>>> button
>>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>>>>
>>> allows
>>>
>>>> you to select target entity, cardinality (to-one, to-many) and continue
>>>>
>>> to
>>>
>>>> the joins mapping?
>>>>
>>>
>>>
>>> +1. The UI is a bit overloaded at the moment. Another option may be
>>> to implement the dialog as a frame with tab panes.
>>>
>>> I'm still not a super huge fan of the constant expansion, but I think
>>> the improvements made are making it less of an issue.
>>>
>>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>>> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
>>> I think that would cut down on confusion a bit more.
>>>
>>> --
>>>
>>> Kevin
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Good point... Maybe we can make it a function of the dialog per item
#3... Essentially we take a selected DbRelationship and offer user a
choice to make a new relationship either out of the source or the
target of that relationship, with radiobuttons:
Source: Artist <radio>
Source: Painting <radio>
Target: <Dropdown>
To Many: <checkbox>
Andrus
On Nov 12, 2008, at 11:56 AM, Andrey Razumovsky wrote:
> Well, I think at least we need 'Clear Path' button. Otherwise I
> won't be
> able to create new DbRelationship from ObjRelationship source (i.e.
> insert
> new relationship in first column).
>
> 2008/11/12, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Cool. I very much like the direction. Here is a few notes on the
>> implementation:
>>
>> 1. I think "revert" and "clear" are redundant. They don't revert
>> previous
>> "save", but simply go back in the browser. It is just as easy to
>> use the
>> browser to achieve that. So I suggest we remove those buttons.
>>
>> 2. "Save Path" should probably be called "Select", as we are not
>> really
>> saving anything until "Done" is clicked. Also since we only have 1
>> button
>> now, maybe to make things more compact and consistent with other
>> similar
>> interfaces, implement it as a toolbar on top of the browser (see
>> Select
>> Query Ordering tab for an example).
>>
>> 3. DbRelationships. There's a bit of a problem figuring context of
>> the new
>> relationship. It correctly uses a target of the currently selected
>> DbRelationship path as its source, however its location is disjoint
>> from the
>> browser so it is not immediately clear. It also clutters the view a
>> bit. So
>> maybe we can add an extra dialog started with a "new relationship"
>> button
>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>> allows
>> you to select target entity, cardinality (to-one, to-many) and
>> continue to
>> the joins mapping?
>>
>> Thanks,
>> Andrus
>>
>>
>> On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
>>
>> I commited the new dialog. Please spend some time trying it out and
>> tell me
>>> if you like it. Comments about its way of work is in JIRA
>>>
>>> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>>
>>>>
>>>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>>>
>>>> Fine, but as af as I remember, "Target" should be combobox
>>>> because 1)
>>>> There
>>>>
>>>>> can be more than one ObjEntity for DbEntity
>>>>>
>>>>>
>>>> Good point. Then I guess we need to limit combo choices only to
>>>> those
>>>> entities that apply for a given path.
>>>>
>>>> 2) User can add new Db Rels in
>>>>
>>>>> this dialog by clicking "New to-X relationship" (and target will
>>>>> be what
>>>>> was
>>>>> selected in combobox)
>>>>>
>>>>>
>>>> I suggest we stop using the combo for targeting (except for the
>>>> special
>>>> case above). This creates UI redundancy that can potentially be
>>>> confusing.
>>>> So maybe we add a "target" combo to the DbRelationship mapping
>>>> dialog
>>>> instead? (Maybe only shown when the dialog is opened from
>>>> ObjRelationship
>>>> dialog; and hidden otherwise)?
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Well, I think at least we need 'Clear Path' button. Otherwise I won't be
able to create new DbRelationship from ObjRelationship source (i.e. insert
new relationship in first column).
2008/11/12, Andrus Adamchik <an...@objectstyle.org>:
>
> Cool. I very much like the direction. Here is a few notes on the
> implementation:
>
> 1. I think "revert" and "clear" are redundant. They don't revert previous
> "save", but simply go back in the browser. It is just as easy to use the
> browser to achieve that. So I suggest we remove those buttons.
>
> 2. "Save Path" should probably be called "Select", as we are not really
> saving anything until "Done" is clicked. Also since we only have 1 button
> now, maybe to make things more compact and consistent with other similar
> interfaces, implement it as a toolbar on top of the browser (see Select
> Query Ordering tab for an example).
>
> 3. DbRelationships. There's a bit of a problem figuring context of the new
> relationship. It correctly uses a target of the currently selected
> DbRelationship path as its source, however its location is disjoint from the
> browser so it is not immediately clear. It also clutters the view a bit. So
> maybe we can add an extra dialog started with a "new relationship" button
> icon on the browser toolbar (see #2 - we will have a toolbar), that allows
> you to select target entity, cardinality (to-one, to-many) and continue to
> the joins mapping?
>
> Thanks,
> Andrus
>
>
> On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
>
> I commited the new dialog. Please spend some time trying it out and tell me
>> if you like it. Comments about its way of work is in JIRA
>>
>> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>>
>>>
>>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>>
>>> Fine, but as af as I remember, "Target" should be combobox because 1)
>>> There
>>>
>>>> can be more than one ObjEntity for DbEntity
>>>>
>>>>
>>> Good point. Then I guess we need to limit combo choices only to those
>>> entities that apply for a given path.
>>>
>>> 2) User can add new Db Rels in
>>>
>>>> this dialog by clicking "New to-X relationship" (and target will be what
>>>> was
>>>> selected in combobox)
>>>>
>>>>
>>> I suggest we stop using the combo for targeting (except for the special
>>> case above). This creates UI redundancy that can potentially be
>>> confusing.
>>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>>> instead? (Maybe only shown when the dialog is opened from ObjRelationship
>>> dialog; and hidden otherwise)?
>>>
>>> Andrus
>>>
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Very nice.
I guess there are still ways to arrange things a little different here
and there, but now the functionality is straightforward and there is
little room for confusion.
One minor note - let's change "Done" button in the "New
DbRelationship" dialog to "Continue". Otherwise I think this is
finished.
Andrus
On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
> I've committed the dialog. Please have a look, and let's get over
> with it
>
> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>
>> Comments are in-line.
>>
>>
>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>> >
>> wrote:
>>> Cool. I very much like the direction. Here is a few notes on the
>>> implementation:
>>>
>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>> previous
>>> "save", but simply go back in the browser. It is just as easy to
>>> use the
>>> browser to achieve that. So I suggest we remove those buttons.
>>
>>
>> Are you seeing something different than me? If I modify an existing
>> relationship, revert takes me back to that mapped relationship.
>> Clear
>> removes all selection.
>>
>>
>>> 2. "Save Path" should probably be called "Select", as we are not
>>> really
>>> saving anything until "Done" is clicked. Also since we only have 1
>>> button
>>> now, maybe to make things more compact and consistent with other
>>> similar
>>> interfaces, implement it as a toolbar on top of the browser (see
>>> Select
>>> Query Ordering tab for an example).
>>
>>
>> +1.
>>
>>
>>> 3. DbRelationships. There's a bit of a problem figuring context of
>>> the
>> new
>>> relationship. It correctly uses a target of the currently selected
>>> DbRelationship path as its source, however its location is
>>> disjoint from
>> the
>>> browser so it is not immediately clear. It also clutters the view
>>> a bit.
>> So
>>> maybe we can add an extra dialog started with a "new relationship"
>>> button
>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>> allows
>>> you to select target entity, cardinality (to-one, to-many) and
>>> continue
>> to
>>> the joins mapping?
>>
>>
>> +1. The UI is a bit overloaded at the moment. Another option may be
>> to implement the dialog as a frame with tab panes.
>>
>> I'm still not a super huge fan of the constant expansion, but I think
>> the improvements made are making it less of an issue.
>>
>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>> We could also cull 1 - m, m - 1, since the 1 is the same in each
>> case.
>> I think that would cut down on confusion a bit more.
>>
>> --
>>
>> Kevin
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
I've committed the dialog. Please have a look, and let's get over with it
2008/11/14, Kevin Menard <ni...@gmail.com>:
>
> Comments are in-line.
>
>
> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> > Cool. I very much like the direction. Here is a few notes on the
> > implementation:
> >
> > 1. I think "revert" and "clear" are redundant. They don't revert previous
> > "save", but simply go back in the browser. It is just as easy to use the
> > browser to achieve that. So I suggest we remove those buttons.
>
>
> Are you seeing something different than me? If I modify an existing
> relationship, revert takes me back to that mapped relationship. Clear
> removes all selection.
>
>
> > 2. "Save Path" should probably be called "Select", as we are not really
> > saving anything until "Done" is clicked. Also since we only have 1 button
> > now, maybe to make things more compact and consistent with other similar
> > interfaces, implement it as a toolbar on top of the browser (see Select
> > Query Ordering tab for an example).
>
>
> +1.
>
>
> > 3. DbRelationships. There's a bit of a problem figuring context of the
> new
> > relationship. It correctly uses a target of the currently selected
> > DbRelationship path as its source, however its location is disjoint from
> the
> > browser so it is not immediately clear. It also clutters the view a bit.
> So
> > maybe we can add an extra dialog started with a "new relationship" button
> > icon on the browser toolbar (see #2 - we will have a toolbar), that
> allows
> > you to select target entity, cardinality (to-one, to-many) and continue
> to
> > the joins mapping?
>
>
> +1. The UI is a bit overloaded at the moment. Another option may be
> to implement the dialog as a frame with tab panes.
>
> I'm still not a super huge fan of the constant expansion, but I think
> the improvements made are making it less of an issue.
>
> I'd also like to see a bit more culling. Right now 1-1 are culled.
> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
> I think that would cut down on confusion a bit more.
>
> --
>
> Kevin
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Comments are in-line.
On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Cool. I very much like the direction. Here is a few notes on the
> implementation:
>
> 1. I think "revert" and "clear" are redundant. They don't revert previous
> "save", but simply go back in the browser. It is just as easy to use the
> browser to achieve that. So I suggest we remove those buttons.
Are you seeing something different than me? If I modify an existing
relationship, revert takes me back to that mapped relationship. Clear
removes all selection.
> 2. "Save Path" should probably be called "Select", as we are not really
> saving anything until "Done" is clicked. Also since we only have 1 button
> now, maybe to make things more compact and consistent with other similar
> interfaces, implement it as a toolbar on top of the browser (see Select
> Query Ordering tab for an example).
+1.
> 3. DbRelationships. There's a bit of a problem figuring context of the new
> relationship. It correctly uses a target of the currently selected
> DbRelationship path as its source, however its location is disjoint from the
> browser so it is not immediately clear. It also clutters the view a bit. So
> maybe we can add an extra dialog started with a "new relationship" button
> icon on the browser toolbar (see #2 - we will have a toolbar), that allows
> you to select target entity, cardinality (to-one, to-many) and continue to
> the joins mapping?
+1. The UI is a bit overloaded at the moment. Another option may be
to implement the dialog as a frame with tab panes.
I'm still not a super huge fan of the constant expansion, but I think
the improvements made are making it less of an issue.
I'd also like to see a bit more culling. Right now 1-1 are culled.
We could also cull 1 - m, m - 1, since the 1 is the same in each case.
I think that would cut down on confusion a bit more.
--
Kevin
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Cool. I very much like the direction. Here is a few notes on the
implementation:
1. I think "revert" and "clear" are redundant. They don't revert
previous "save", but simply go back in the browser. It is just as easy
to use the browser to achieve that. So I suggest we remove those
buttons.
2. "Save Path" should probably be called "Select", as we are not
really saving anything until "Done" is clicked. Also since we only
have 1 button now, maybe to make things more compact and consistent
with other similar interfaces, implement it as a toolbar on top of the
browser (see Select Query Ordering tab for an example).
3. DbRelationships. There's a bit of a problem figuring context of the
new relationship. It correctly uses a target of the currently selected
DbRelationship path as its source, however its location is disjoint
from the browser so it is not immediately clear. It also clutters the
view a bit. So maybe we can add an extra dialog started with a "new
relationship" button icon on the browser toolbar (see #2 - we will
have a toolbar), that allows you to select target entity, cardinality
(to-one, to-many) and continue to the joins mapping?
Thanks,
Andrus
On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
> I commited the new dialog. Please spend some time trying it out and
> tell me
> if you like it. Comments about its way of work is in JIRA
>
> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>
>> Fine, but as af as I remember, "Target" should be combobox because
>> 1) There
>>> can be more than one ObjEntity for DbEntity
>>>
>>
>> Good point. Then I guess we need to limit combo choices only to those
>> entities that apply for a given path.
>>
>> 2) User can add new Db Rels in
>>> this dialog by clicking "New to-X relationship" (and target will
>>> be what
>>> was
>>> selected in combobox)
>>>
>>
>> I suggest we stop using the combo for targeting (except for the
>> special
>> case above). This creates UI redundancy that can potentially be
>> confusing.
>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>> instead? (Maybe only shown when the dialog is opened from
>> ObjRelationship
>> dialog; and hidden otherwise)?
>>
>> Andrus
>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
I commited the new dialog. Please spend some time trying it out and tell me
if you like it. Comments about its way of work is in JIRA
2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>
> Fine, but as af as I remember, "Target" should be combobox because 1) There
>> can be more than one ObjEntity for DbEntity
>>
>
> Good point. Then I guess we need to limit combo choices only to those
> entities that apply for a given path.
>
> 2) User can add new Db Rels in
>> this dialog by clicking "New to-X relationship" (and target will be what
>> was
>> selected in combobox)
>>
>
> I suggest we stop using the combo for targeting (except for the special
> case above). This creates UI redundancy that can potentially be confusing.
> So maybe we add a "target" combo to the DbRelationship mapping dialog
> instead? (Maybe only shown when the dialog is opened from ObjRelationship
> dialog; and hidden otherwise)?
>
> Andrus
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
> Fine, but as af as I remember, "Target" should be combobox because
> 1) There
> can be more than one ObjEntity for DbEntity
Good point. Then I guess we need to limit combo choices only to those
entities that apply for a given path.
> 2) User can add new Db Rels in
> this dialog by clicking "New to-X relationship" (and target will be
> what was
> selected in combobox)
I suggest we stop using the combo for targeting (except for the
special case above). This creates UI redundancy that can potentially
be confusing. So maybe we add a "target" combo to the DbRelationship
mapping dialog instead? (Maybe only shown when the dialog is opened
from ObjRelationship dialog; and hidden otherwise)?
Andrus
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Fine, but as af as I remember, "Target" should be combobox because 1) There
can be more than one ObjEntity for DbEntity 2) User can add new Db Rels in
this dialog by clicking "New to-X relationship" (and target will be what was
selected in combobox)
2008/11/8, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 8, 2008, at 8:52 PM, Andrey Razumovsky wrote:
>
> About M5, I'm still not sure what should we do with CAY-1077. Switching
>> between single and double click is a minute work and I'd prefer we close
>> it
>> and release M5 as fast as possible.
>>
>
> Sorry, I kept postponing replying to this. Let me give it a shot now... I
> stand by my earlier assessment - the browser has to expand on a single
> click... looking at the comment in Jira by Kevin, "the behavior of the
> column selector should be the same for the relationship dialog and the
> prefetch dialog.", I think I am totally in favor of following this approach.
> Here is what it means IMO:
>
> 1. The browser should expand on single click
> 2. "Target" should be a text label, not a dropdown.
>
> 3. (??) How do we allow a user to navigate through relationships without
> dirtying the selection... It is probably evil to make a single click
> selection as it is unclear to the users that they've just changed something,
> when they simply wanted to browse around, so let's make selection a separate
> step following prefetch/ordering selection process for queries. So let's add
> a "select path" button, similar to "Add Ordering" button for select queries
> (there won't be a "remove" I guess, as we are only selecting 1 path). Maybe
> we can also improve on the browser - a relationship target entity can be
> shown as a column header of the browser panel on the right of the
> relationship.
>
> Does this sound reasonable?
>
> Andrus
>
>
>