rop-browser design

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

Hi folks,

I guess most of you haven't seen what I'm doing, but I thought I'd ask 
for some input via the mailing list since that's The Way It's Done Round 
Here. I am working on an Eclipse plugin which allows DB editing via 
Cayenne's object model and ROP.

There is a picture at [1] which shows the problem at hand. Using the 
Artist - Painting - Gallery DB, when a new Painting is created, its 
Gallery needs to be set. It can easily be set to a new Gallery, but I 
may want to set it to an existing one, which may not be displayed in the 
diagram. More generally, I need a way to set an object in the diagram to 
an instance which is already in the DB, but not yet displayed in the 
diagram. All the other processes are entirely visual at present, so I'm 
reluctant to add dialogs, but...

At the moment I think the best (read 'only practical') way to do it is 
via a wizard. The user selects a NamedQuery from the map, sets key/value 
parameters, and picks from the results.

I was wondering if anyone had any other ideas, or suggestions that would 
improve a process like that.

Cheers,

Marcel

[1] http://www.uow.edu.au/~mgordon/insert.png

Re: rop-browser design

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

>>> At the moment I think the best (read 'only practical') way to do it 
>>> is via a wizard. The user selects a NamedQuery from the map, sets 
>>> key/value parameters, and picks from the results.
>>
>> How about expanding the control panel capabilities? Current control 
>> panel opens a new "Object Editor" window on every query run. We can 
>> do two things:
>>
>> * (optionally) open the results in the same Object Editor.
> I see where you are coming from, but this would introduce quite some 
> complexity because the automatic graph layout algorithm relies on the 
> graph being fully connected. I have seen an application where dummy 
> edges are introduced to counter this, but it compromises the algorithm 
> to a certain extent - in the normal case the layout isn't as good.
>
Just a note: the latest version of GEF seems to allow for graphs which 
are not fully connected - nice! So I'll work this in.

Marcel

Re: rop-browser design

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

Jumping back a little bit as I catch up...
>> All the other processes are entirely visual at present, so I'm 
>> reluctant to add dialogs, but...
>
> Actually I wouldn't mind dropdowns in other places, such as collection 
> navigation.
I agree, it would be nice to have a 'jump to' for collections. However I 
can't draw controls on the canvas, so it would have to come in some sort 
of dialog or sit in the control panel (actually I might be able to place 
it in the Properties view). There would have to be two drop-downs, one 
which selects the attribute to use for navigation and the other for 
selecting the actual record using that attribute. How does that sound?

Actually I can do better (I'll leave those ideas there though in case 
they inspire any others). I can place two buttons side by side at the 
bottom of the collection (basic buttons can be drawn), and have clicking 
on them trigger popup/context menus so that they effectively function 
like combo boxes.
>
>> At the moment I think the best (read 'only practical') way to do it 
>> is via a wizard. The user selects a NamedQuery from the map, sets 
>> key/value parameters, and picks from the results.
>
> How about expanding the control panel capabilities? Current control 
> panel opens a new "Object Editor" window on every query run. We can do 
> two things:
>
> * (optionally) open the results in the same Object Editor.
I see where you are coming from, but this would introduce quite some 
complexity because the automatic graph layout algorithm relies on the 
graph being fully connected. I have seen an application where dummy 
edges are introduced to counter this, but it compromises the algorithm 
to a certain extent - in the normal case the layout isn't as good.
> * support entering query parameters when running the query (judging by 
> your earlier questions, you were looking at parameterized queries 
> already). This way users can pinpoint the right object.
>
> One catch with the last point is that supported parameter names are 
> not available via the metadata. So the user will have to specify 
> values and *keys*. In the future we may provide a collection of valid 
> keys via EntityResolver.
The other thing I can do is allow users to run SelectQueries against a 
specified entity name, entering criteria. That is how the wizard for 
Insert Existing runs at the moment.

Dealing with inserting existing objects has been difficult. There are a 
few idiosyncrasies that I need to iron out, but it is mostly functional. 
Next is 'Remove from collection'.

Marcel

Re: rop-browser design

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

Rereading your message, I almost repeated what you said, only placed  
it in control panel :-)

So yeah, either way would work... And user-friendly collection  
navigator should help here as well.

Andrus

On Jul 24, 2006, at 4:35 PM, Andrus Adamchik wrote:

>
>> At the moment I think the best (read 'only practical') way to do  
>> it is via a wizard. The user selects a NamedQuery from the map,  
>> sets key/value parameters, and picks from the results.
>
> How about expanding the control panel capabilities? Current control  
> panel opens a new "Object Editor" window on every query run. We can  
> do two things:
>
> * (optionally) open the results in the same Object Editor.
> * support entering query parameters when running the query (judging  
> by your earlier questions, you were looking at parameterized  
> queries already). This way users can pinpoint the right object.
>
> One catch with the last point is that supported parameter names are  
> not available via the metadata. So the user will have to specify  
> values and *keys*. In the future we may provide a collection of  
> valid keys via EntityResolver.

Re: rop-browser design

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

On Jul 24, 2006, at 2:19 AM, Marcel wrote:
> I guess most of you haven't seen what I'm doing, but I thought I'd  
> ask for some input via the mailing list since that's The Way It's  
> Done Round Here.

yep.

> There is a picture at [1] which shows the problem at hand. Using  
> the Artist - Painting - Gallery DB, when a new Painting is created,  
> its Gallery needs to be set. It can easily be set to a new Gallery,  
> but I may want to set it to an existing one, which may not be  
> displayed in the diagram. More generally, I need a way to set an  
> object in the diagram to an instance which is already in the DB,  
> but not yet displayed in the diagram.

I was going to point out to that problem before as well. I beat me on  
that.


> All the other processes are entirely visual at present, so I'm  
> reluctant to add dialogs, but...

Actually I wouldn't mind dropdowns in other places, such as  
collection navigation. While I like the latest UI a lot, I still find  
it hard to get around finding an object in a collection, and often  
confuse collections with single objects cause they look the same. But  
that's beyond the point...

> At the moment I think the best (read 'only practical') way to do it  
> is via a wizard. The user selects a NamedQuery from the map, sets  
> key/value parameters, and picks from the results.

How about expanding the control panel capabilities? Current control  
panel opens a new "Object Editor" window on every query run. We can  
do two things:

* (optionally) open the results in the same Object Editor.
* support entering query parameters when running the query (judging  
by your earlier questions, you were looking at parameterized queries  
already). This way users can pinpoint the right object.

One catch with the last point is that supported parameter names are  
not available via the metadata. So the user will have to specify  
values and *keys*. In the future we may provide a collection of valid  
keys via EntityResolver.

Andrus