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
This archive was generated by hypermail 2.0.0 : Thu Jul 27 2006 - 00:05:14 EDT