You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <bl...@gmail.com> on 2016/03/28 22:06:29 UTC
Cayenne Modeler Prototype
I've spent a few days starting a prototype for a JavaFX-based version of
Cayenne Modeler. Andrus suggested I share some screenshots with the list,
so here they are:
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataDomain.png
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataMap.png
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity1.png
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity2.png
The UI is done almost entirely using FXML files and SceneBuilder, so it is
fairly easy to change around.
I was using the 3.1 CM as a basis, but will switch things over to the 4.0
CM shortly.
One thing I'm curious about is with the 4.0 CM, the
attributes/relationships tabs have been merged. With the approach I was
taking, keeping them separate allowed an "inspector" to appear below the
the attributes (I was going to take the same approach for relationships) so
that you don't have to deal with a popup inspector. I think this is very
useful when adding the JavaDoc and Annotations support. Having the
inspector there obviously takes up valuable screen space, so I'm concerned
that if the attributes and relationships remain merged, as in the 4.0 CM,
the display area would be quite tight. Maybe we should keep them separate?
I've spent 3-4 days on it thus far, but would love some constructive
feedback, especially if I'm heading down a bad path.
Thanks,
mrg
Re: Cayenne Modeler Prototype
Posted by Andrus Adamchik <an...@objectstyle.org>.
Nice! If we all like them, I can probably find a designer to create hi-res versions.
Andrus
> On Mar 29, 2016, at 11:11 AM, Andrew Lindesay <ap...@lindesay.co.nz> wrote:
>
> Hello Michael;
>
> It is great that you are able to make some improvements to the modeller.
>
> Some years ago I spent some time drafting-up some replacement icons.
> Unfortunately they are not high-resolution and, with current
> commitments, I am unlikely to be able to complete them at this time...
>
> http://www.silvereye.co.nz/tmp/cayenne-icons.pdf
>
> The concept was that red things are Cayenne and blue/grey/purple with
> red/green/purple stipple are database.
>
> Regards;
>
> --
> Andrew Lindesay
> apl@lindesay.co.nz
>
> On Tue, Mar 29, 2016, at 09:06, Michael Gentry wrote:
>> I've spent a few days starting a prototype for a JavaFX-based version of
>> Cayenne Modeler. Andrus suggested I share some screenshots with the
>> list,
>> so here they are:
>>
>>
>> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataDomain.png
>>
>> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataMap.png
>>
>> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity1.png
>>
>> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity2.png
>>
>>
>> The UI is done almost entirely using FXML files and SceneBuilder, so it
>> is
>> fairly easy to change around.
>>
>> I was using the 3.1 CM as a basis, but will switch things over to the 4.0
>> CM shortly.
>>
>> One thing I'm curious about is with the 4.0 CM, the
>> attributes/relationships tabs have been merged. With the approach I was
>> taking, keeping them separate allowed an "inspector" to appear below the
>> the attributes (I was going to take the same approach for relationships)
>> so
>> that you don't have to deal with a popup inspector. I think this is very
>> useful when adding the JavaDoc and Annotations support. Having the
>> inspector there obviously takes up valuable screen space, so I'm
>> concerned
>> that if the attributes and relationships remain merged, as in the 4.0 CM,
>> the display area would be quite tight. Maybe we should keep them
>> separate?
>>
>> I've spent 3-4 days on it thus far, but would love some constructive
>> feedback, especially if I'm heading down a bad path.
>>
>> Thanks,
>>
>> mrg
Re: Cayenne Modeler Prototype
Posted by Andrew Lindesay <ap...@lindesay.co.nz>.
Hello Michael;
It is great that you are able to make some improvements to the modeller.
Some years ago I spent some time drafting-up some replacement icons.
Unfortunately they are not high-resolution and, with current
commitments, I am unlikely to be able to complete them at this time...
http://www.silvereye.co.nz/tmp/cayenne-icons.pdf
The concept was that red things are Cayenne and blue/grey/purple with
red/green/purple stipple are database.
Regards;
--
Andrew Lindesay
apl@lindesay.co.nz
On Tue, Mar 29, 2016, at 09:06, Michael Gentry wrote:
> I've spent a few days starting a prototype for a JavaFX-based version of
> Cayenne Modeler. Andrus suggested I share some screenshots with the
> list,
> so here they are:
>
>
> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataDomain.png
>
> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataMap.png
>
> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity1.png
>
> https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntity2.png
>
>
> The UI is done almost entirely using FXML files and SceneBuilder, so it
> is
> fairly easy to change around.
>
> I was using the 3.1 CM as a basis, but will switch things over to the 4.0
> CM shortly.
>
> One thing I'm curious about is with the 4.0 CM, the
> attributes/relationships tabs have been merged. With the approach I was
> taking, keeping them separate allowed an "inspector" to appear below the
> the attributes (I was going to take the same approach for relationships)
> so
> that you don't have to deal with a popup inspector. I think this is very
> useful when adding the JavaDoc and Annotations support. Having the
> inspector there obviously takes up valuable screen space, so I'm
> concerned
> that if the attributes and relationships remain merged, as in the 4.0 CM,
> the display area would be quite tight. Maybe we should keep them
> separate?
>
> I've spent 3-4 days on it thus far, but would love some constructive
> feedback, especially if I'm heading down a bad path.
>
> Thanks,
>
> mrg
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
Forgot to mention this:
"No more editing in tables which can be non-intuitive if you don't know
where to click"
The way I am currently putting it together doesn't allow you to edit in the
table. All of the editing is done in the bottom part. So the attribute
name, Java type, DB column, JavaDoc, etc, are all edited in the detail/edit
view for the attribute. The main reason to keep the attributes table is to
allow sorting and a quick glance at a lot of the data without having to
click through them one-at-a-time.
Thanks,
mrg
On Tue, Mar 29, 2016 at 5:36 AM, Michael Gentry <bl...@gmail.com> wrote:
> On Tue, Mar 29, 2016 at 12:55 AM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
>
>> I can see what you are doing with the "inspector" however I don't think
>> the hierarchy of information is very clear. That is, a user can understand
>> the left tree shows DataDomain -> DataMap -> ObjEntity. And then they are
>> shown a list of attributes and other properties of that ObjEntity in the
>> right panel when they click in the tree.
>>
>> It is also clear that each of those properties (eg an attribute or
>> relation) has a number of 'options' they can adjust, displayed in columns:
>> name, Java type, path, etc.
>>
>> However I think it becomes confusing to then show additional options in a
>> panel at the bottom: annotations, docs, etc.
>>
>>
>> Possible solutions:
>>
>> 1. Move ObjEntity properties into the tree on the left. For an example of
>> such an approach (from MySQL Workbench) look at this:
>>
>> https://dl.dropboxusercontent.com/u/14832257/tree%20with%20attributes.png
>
>
>
> The concern I'd have with the MySQL Workbench approach is there'd be a lot
> more scrolling involved. The model I have is already fairly large and I
> don't like scrolling around it looking for things. If I had to expand
> attributes (and relationships) and select the property to edit, I think the
> amount of scrolling would become quite hectic. On my 27" iMac with CM 3.1
> taking up the full vertical height of the screen, the tree view is about
> 1/2 shown. At least one ObjEntity has enough attributes to more than fill
> the vertical height, too. If all of those properties start getting
> expanded in the tree view, it would become quite chaotic, I think.
>
> The reason for the JavaDoc, Imports, Annotations at the bottom (and I
> haven't started the relationship tab yet) is it closely binds it to the
> item you are editing.
>
> The Class tab has JavaDoc/Imports just for that class. The Attributes
> tab, when you select an attribute to edit, will show the
> JavaDoc/Annotations just for that attribute. I expect the Relationships
> tab to be similar (if we keep it separate). If there are separate
> JavaDoc/etc tabs, there would have to be sections for the class JavaDoc, a
> list/pulldown for you to select attribute/relationship properties to edit
> JavaDoc/Annotations, etc. Having to re-specify this information again
> seems redundant to me and would discourage use, I think. Plus, I think it
> it is nicer to see all of that information in one place without having to
> click around and make extra selections.
>
> Thanks,
>
> mrg
>
>
>
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
A couple new screenshots:
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/Splash.png
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/MultipleWindows.png
For the splash screen, the recent projects are now contained in a list
which allows keyboard navigation (and pressing return to open a project),
plus you can also tab-navigate to the open/new buttons (which admittedly
don't work yet) and hit the space bar (at least on OS X) to activate. The
ability to scroll the project list horizontally means you can actually see
long paths, too, which is a serious limitation in the current CM.
Multiple editor windows can be opened. There is still a lot of work to do
in getting all the editing features wired up, but it is quite easy to
create additional editor windows now. Also, I plan on allowing multiple
editor windows for the same project, too, which means synchronization
across windows will be important (something more to add).
mrg
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
The thing is, if I have to expand something, then I also have to collapse
it, which is something I have to mentally remember to do in order to
control my tree size, which is an added burden. I think auto-collapsing
(like an accordion) wouldn't be user-friendly, although this could be a
preference setting, I suppose. I understand the desire to have more room
available for the editor, but i don't think it feels too crammed at the
bottom of the table.
Keep in mind, too, I am planning on additional functionality in the tree
view, it just isn't there yet. I am planning on having relationships (not
attributes) expandable under each entity in the tree view so you could
drill through the relationships there to reach other entities.
In my model, as an example:
LineItem -> Item -> Manufacturer -> CostElement -> CostElementCategory
-> ...
In the current CM, I have to go to the relationship tab to see the
relationship, then hunt around for the related entity in the tree view to
find the other relationships. It is disjointed and non-relational and I
don't like hunting around for it. I was planning something more like
EOModeler where your tree view would allow this (hopefully the formatting
is preserved):
[+] LineItem
[+] Item
[+] Manufacturer
[+] CostElement
[+] CostElementCategory
[+] ...
This would allow you to focus on a group of related objects (which is how I
tend to edit models) without having to bounce all over the tree view as
much. Selecting the Manufacturer would open up the ObjEntity editor for
the Manufacturer, but you can easily select one of the other closely
related entities to edit in that graph. Having the attributes in the tree
would make that feature nearly useless as it would introduce too much
scrolling in the tree view and your relationships wouldn't be kept
together. I suppose you could add a [+] to expand the attributes, but that
still introduces more vertical space and you have to expand the attributes
to edit them.
This screenshot is small, but maybe it'll help illustrate:
http://stpeterandpaul.ca/tiger/documentation/WebObjects/UsingEOModeler/Art/entity_selected_intree.gif
You can click the [+] beside the Administrator to see relationships
under/associated with it and you can keep drilling down through the object
model.
mrg
On Tue, Mar 29, 2016 at 7:27 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
> On 29/03/2016 8:36pm, Michael Gentry wrote:
> > The concern I'd have with the MySQL Workbench approach is there'd be a
> lot
> > more scrolling involved. The model I have is already fairly large and I
> > don't like scrolling around it looking for things. If I had to expand
> > attributes (and relationships) and select the property to edit, I think
> the
> > amount of scrolling would become quite hectic. On my 27" iMac with CM
> 3.1
> > taking up the full vertical height of the screen, the tree view is about
> > 1/2 shown. At least one ObjEntity has enough attributes to more than
> fill
> > the vertical height, too. If all of those properties start getting
> > expanded in the tree view, it would become quite chaotic, I think.
>
> Let's talk about this point specifically. In MySQL Workbench there is
> exactly the same problem... very very long lists. One of my db servers has
> 60 databases and each database has about 120 tables. Each table might
> average 15 columns.
>
> But of course you never have the whole thing expanded at once. Typically
> you'd use it just like you would the three panel approach with a similar
> number of clicks. The tree only becomes unhelpful if you expand lots of
> things at once and maybe an accordion approach (where expanding one thing
> collapses everything else) could work.
>
> The only reason I really like this approach though is how much more room
> is available for the editor, rather than cramming it into the bottom 20% of
> the frame. Everything else apart from the editor is just navigation.
>
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: Cayenne Modeler Prototype
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 29, 2016, at 2:27 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> But of course you never have the whole thing expanded at once. Typically you'd use it just like you would the three panel approach with a similar number of clicks. The tree only becomes unhelpful if you expand lots of things at once and maybe an accordion approach (where expanding one thing collapses everything else) could work.
>
> The only reason I really like this approach though is how much more room is available for the editor, rather than cramming it into the bottom 20% of the frame. Everything else apart from the editor is just navigation.
Kind of like Eclipse Java Perspective:
https://www.dropbox.com/s/to39vjp02oaa7rp/screen.png?dl=0
I can expand classes on the left, but I never do in practice, as the tree becomes unwieldy. Splitting it between project/package view and class properties view seems ideal. Java class model.
Andrus
Re: Cayenne Modeler Prototype
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 29/03/2016 8:36pm, Michael Gentry wrote:
> The concern I'd have with the MySQL Workbench approach is there'd be a lot
> more scrolling involved. The model I have is already fairly large and I
> don't like scrolling around it looking for things. If I had to expand
> attributes (and relationships) and select the property to edit, I think the
> amount of scrolling would become quite hectic. On my 27" iMac with CM 3.1
> taking up the full vertical height of the screen, the tree view is about
> 1/2 shown. At least one ObjEntity has enough attributes to more than fill
> the vertical height, too. If all of those properties start getting
> expanded in the tree view, it would become quite chaotic, I think.
Let's talk about this point specifically. In MySQL Workbench there is exactly the same problem... very very long lists. One of my db servers has 60 databases and each database has about 120 tables. Each table might average 15 columns.
But of course you never have the whole thing expanded at once. Typically you'd use it just like you would the three panel approach with a similar number of clicks. The tree only becomes unhelpful if you expand lots of things at once and maybe an accordion approach (where expanding one thing collapses everything else) could work.
The only reason I really like this approach though is how much more room is available for the editor, rather than cramming it into the bottom 20% of the frame. Everything else apart from the editor is just navigation.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
On Tue, Mar 29, 2016 at 12:55 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
> I can see what you are doing with the "inspector" however I don't think
> the hierarchy of information is very clear. That is, a user can understand
> the left tree shows DataDomain -> DataMap -> ObjEntity. And then they are
> shown a list of attributes and other properties of that ObjEntity in the
> right panel when they click in the tree.
>
> It is also clear that each of those properties (eg an attribute or
> relation) has a number of 'options' they can adjust, displayed in columns:
> name, Java type, path, etc.
>
> However I think it becomes confusing to then show additional options in a
> panel at the bottom: annotations, docs, etc.
>
>
> Possible solutions:
>
> 1. Move ObjEntity properties into the tree on the left. For an example of
> such an approach (from MySQL Workbench) look at this:
>
> https://dl.dropboxusercontent.com/u/14832257/tree%20with%20attributes.png
The concern I'd have with the MySQL Workbench approach is there'd be a lot
more scrolling involved. The model I have is already fairly large and I
don't like scrolling around it looking for things. If I had to expand
attributes (and relationships) and select the property to edit, I think the
amount of scrolling would become quite hectic. On my 27" iMac with CM 3.1
taking up the full vertical height of the screen, the tree view is about
1/2 shown. At least one ObjEntity has enough attributes to more than fill
the vertical height, too. If all of those properties start getting
expanded in the tree view, it would become quite chaotic, I think.
The reason for the JavaDoc, Imports, Annotations at the bottom (and I
haven't started the relationship tab yet) is it closely binds it to the
item you are editing.
The Class tab has JavaDoc/Imports just for that class. The Attributes tab,
when you select an attribute to edit, will show the JavaDoc/Annotations
just for that attribute. I expect the Relationships tab to be similar (if
we keep it separate). If there are separate JavaDoc/etc tabs, there would
have to be sections for the class JavaDoc, a list/pulldown for you to
select attribute/relationship properties to edit JavaDoc/Annotations, etc.
Having to re-specify this information again seems redundant to me and would
discourage use, I think. Plus, I think it it is nicer to see all of that
information in one place without having to click around and make extra
selections.
Thanks,
mrg
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
On Tue, Mar 29, 2016 at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
> On 29/03/2016 9:05pm, Michael Gentry wrote:
> >
> > I can absolutely share. Do you want just the FXML files? I still have
> > re-factoring work to do (the ObjEntity tab views are all in one FXML file
> > currently, and I want to split it out into separate view
> files/controllers,
> > for example -- one controller/view per tab), so I'm expecting them to
> > change quite a bit. My hope is that sometime next week I'll have it
> > cleaned up enough to share all of it (Java, READMEs, etc). Keep in mind
> > this is very much a prototype/hack and I'm learning JavaFX as I go (only
> > spent ~4 days on it so far).
>
> Yeah, I'm new to JavaFX too. But I think I just need the XML to open it in
> SceneBuilder and play with the UI?
>
I'm pretty sure you can open the FXML files without the code. You'll want
to download Scene Builder first:
http://gluonhq.com/open-source/scene-builder/
Here are the current FXML files:
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataDomainView.fxml
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/DataMapView.fxml
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/MainScene.fxml
https://dl.dropboxusercontent.com/u/54311650/CayenneModelerPrototype/ObjectEntityView.fxml
Keep in mind, I'm planning on a lot of refactoring, especially the
ObjEntity one, but it might take me a few days.
> > I think the other problem to solve is the icons. Myself, I typically use
> >> > Cayenne Modeler once every few months. So every time I use it, I'm
> clicking
> >> > on icons to try and remember which one is which. Is blob-blob-plus a
> new
> >> > relationship?
> >> >
> >
> > Tooltips are required for all of these. Even when I've "lived" in CM, I
> > still used the tooltips a lot...
>
> I'm of the opinion that tooltips are effectively an admission of UX
> failure. if I have to wait 2 seconds after hovering over each icon in turn,
> it's really not a great UI.
>
> For something as complex as a database model, there really just aren't
> icons that mean anything intuitive. So we need to give ourselves room for
> words. Sure, use icons (and colour) to quickly show similar types of
> things. but ultimately only words are going to distinguish the choices.
>
FWIW, we can color the icons pretty easily, I just didn't.
Re: Cayenne Modeler Prototype
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 29/03/2016 9:05pm, Michael Gentry wrote:
>
> I can absolutely share. Do you want just the FXML files? I still have
> re-factoring work to do (the ObjEntity tab views are all in one FXML file
> currently, and I want to split it out into separate view files/controllers,
> for example -- one controller/view per tab), so I'm expecting them to
> change quite a bit. My hope is that sometime next week I'll have it
> cleaned up enough to share all of it (Java, READMEs, etc). Keep in mind
> this is very much a prototype/hack and I'm learning JavaFX as I go (only
> spent ~4 days on it so far).
Yeah, I'm new to JavaFX too. But I think I just need the XML to open it in SceneBuilder and play with the UI?
> I think the other problem to solve is the icons. Myself, I typically use
>> > Cayenne Modeler once every few months. So every time I use it, I'm clicking
>> > on icons to try and remember which one is which. Is blob-blob-plus a new
>> > relationship?
>> >
>
> Tooltips are required for all of these. Even when I've "lived" in CM, I
> still used the tooltips a lot...
I'm of the opinion that tooltips are effectively an admission of UX failure. if I have to wait 2 seconds after hovering over each icon in turn, it's really not a great UI.
For something as complex as a database model, there really just aren't icons that mean anything intuitive. So we need to give ourselves room for words. Sure, use icons (and colour) to quickly show similar types of things. but ultimately only words are going to distinguish the choices.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
Maybe it is my defective brain, but I tend to read/see things better when
organized in columns/grids instead of more free-form, plus it makes more
sense for sorting, but I can explore it.
On Tue, Mar 29, 2016 at 7:07 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> I'd really love to see (1) attribute table, (2) relationship table, (3)
> object editor all in one view. I think we can save space by avoiding lots
> of columns and using longer text labels and icons. E.g.:
>
> myProperty : String <MY_PROPERTY> <lock_icon>
> myRel: SomeEntity
> myCollectionRel: List<SomeEntity>
>
> The only reason individual properties of attributes/relationships are in
> cells now is cause they are editable. Since they won't be editable in the
> new version, we can come up with compact labels.
>
> Andrus
>
> > On Mar 29, 2016, at 1:05 PM, Michael Gentry <bl...@gmail.com> wrote:
> >
> >>
> >> 2. A three panel view. So, Michael's design but with the additional
> >> properties to the right rather than at the bottom.
> >>
> >> This sort of approach is common in email. Tree of mailboxes to the left.
> >> List of messages in the middle and the details to the right. We'd have
> >> domain/map/objentities in the left tree. Attributes in the middle.
> Options
> >> to the right.
> >>
> >> Pros:
> >>
> >> * Left tree is simpler than in option 1
> >> * Shows hierarchy better than option 0 (Michael's mockup)
> >>
> >>
> >> Cons
> >> * Middle panel (list of attributes) would need to have fewer columns
> than
> >> we do now in order to keep the width to a minimum.
> >> * Not as flexible as option 1
> >> * combination of tree and multi-panel approach might be confusing
> >>
> >
> >
> > I thought about doing this, too, but it felt like it would be too wide
> and
> > I like the idea of the attributes table showing me a lot of the
> information
> > at-a-glance. (Admittedly, can't really get the JavaDocs/etc in the
> table,
> > but at least the names/types/locking can be seen quite readily.) You
> > mention e-mail...my Apple Mail layout is set up very similar to this
> > prototype's layout (mailboxes left, messages in mailbox upper right,
> > message thread for selected message lower right). I suppose with
> > wide-screen monitors more popular now, three columns might be doable,
> but I
> > think there is a lot of value in seeing the names/types/locking
> information
> > pretty readily, too, without needing additional work.
>
>
Re: Cayenne Modeler Prototype
Posted by Andrus Adamchik <an...@objectstyle.org>.
> On Mar 29, 2016, at 2:12 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> On 29/03/2016 10:07pm, Andrus Adamchik wrote:
>> I'd really love to see (1) attribute table, (2) relationship table, (3) object editor all in one view. I think we can save space by avoiding lots of columns and using longer text labels and icons. E.g.:
>>
>> myProperty : String <MY_PROPERTY> <lock_icon>
>> myRel: SomeEntity
>> myCollectionRel: List<SomeEntity>
>>
>> The only reason individual properties of attributes/relationships are in cells now is cause they are editable. Since they won't be editable in the new version, we can come up with compact labels.
>
>
> Are you advocating for a three panel type approach (tree -> properties -> editor)? Or merging properties into the tree?
>
> Ari
3 panel. Don't want to see another level of nesting on the main project tree.
Andrus
Re: Cayenne Modeler Prototype
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 29/03/2016 10:07pm, Andrus Adamchik wrote:
> I'd really love to see (1) attribute table, (2) relationship table, (3) object editor all in one view. I think we can save space by avoiding lots of columns and using longer text labels and icons. E.g.:
>
> myProperty : String <MY_PROPERTY> <lock_icon>
> myRel: SomeEntity
> myCollectionRel: List<SomeEntity>
>
> The only reason individual properties of attributes/relationships are in cells now is cause they are editable. Since they won't be editable in the new version, we can come up with compact labels.
Are you advocating for a three panel type approach (tree -> properties -> editor)? Or merging properties into the tree?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Cayenne Modeler Prototype
Posted by Andrus Adamchik <an...@objectstyle.org>.
I'd really love to see (1) attribute table, (2) relationship table, (3) object editor all in one view. I think we can save space by avoiding lots of columns and using longer text labels and icons. E.g.:
myProperty : String <MY_PROPERTY> <lock_icon>
myRel: SomeEntity
myCollectionRel: List<SomeEntity>
The only reason individual properties of attributes/relationships are in cells now is cause they are editable. Since they won't be editable in the new version, we can come up with compact labels.
Andrus
> On Mar 29, 2016, at 1:05 PM, Michael Gentry <bl...@gmail.com> wrote:
>
>>
>> 2. A three panel view. So, Michael's design but with the additional
>> properties to the right rather than at the bottom.
>>
>> This sort of approach is common in email. Tree of mailboxes to the left.
>> List of messages in the middle and the details to the right. We'd have
>> domain/map/objentities in the left tree. Attributes in the middle. Options
>> to the right.
>>
>> Pros:
>>
>> * Left tree is simpler than in option 1
>> * Shows hierarchy better than option 0 (Michael's mockup)
>>
>>
>> Cons
>> * Middle panel (list of attributes) would need to have fewer columns than
>> we do now in order to keep the width to a minimum.
>> * Not as flexible as option 1
>> * combination of tree and multi-panel approach might be confusing
>>
>
>
> I thought about doing this, too, but it felt like it would be too wide and
> I like the idea of the attributes table showing me a lot of the information
> at-a-glance. (Admittedly, can't really get the JavaDocs/etc in the table,
> but at least the names/types/locking can be seen quite readily.) You
> mention e-mail...my Apple Mail layout is set up very similar to this
> prototype's layout (mailboxes left, messages in mailbox upper right,
> message thread for selected message lower right). I suppose with
> wide-screen monitors more popular now, three columns might be doable, but I
> think there is a lot of value in seeing the names/types/locking information
> pretty readily, too, without needing additional work.
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
I was going to do separate e-mails for each point, but now it feels like
too many e-mails and I'm being lazy. :-)
mrg
On Tue, Mar 29, 2016 at 12:55 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
>
> 2. A three panel view. So, Michael's design but with the additional
> properties to the right rather than at the bottom.
>
> This sort of approach is common in email. Tree of mailboxes to the left.
> List of messages in the middle and the details to the right. We'd have
> domain/map/objentities in the left tree. Attributes in the middle. Options
> to the right.
>
> Pros:
>
> * Left tree is simpler than in option 1
> * Shows hierarchy better than option 0 (Michael's mockup)
>
>
> Cons
> * Middle panel (list of attributes) would need to have fewer columns than
> we do now in order to keep the width to a minimum.
> * Not as flexible as option 1
> * combination of tree and multi-panel approach might be confusing
>
I thought about doing this, too, but it felt like it would be too wide and
I like the idea of the attributes table showing me a lot of the information
at-a-glance. (Admittedly, can't really get the JavaDocs/etc in the table,
but at least the names/types/locking can be seen quite readily.) You
mention e-mail...my Apple Mail layout is set up very similar to this
prototype's layout (mailboxes left, messages in mailbox upper right,
message thread for selected message lower right). I suppose with
wide-screen monitors more popular now, three columns might be doable, but I
think there is a lot of value in seeing the names/types/locking information
pretty readily, too, without needing additional work.
> 3. Move the additional options (javadoc, annotations, etc) into floating
> windows like the Relationship Inspector.
>
> Pros:
>
> * Least effort
> * Yeah, nothing else.. its a pretty horrible UI choice.
>
> Cons:
>
> * Ugh
>
I kind of despise those floating inspectors. :-) It feels like hidden
information that should be more immediately presented. I feel I've spent
too much of my life bringing up those inspectors...
I had a quick go at mocking some of these up, but spent so much time
> fighting the tools that I didn't get very far. Michael, if convenient can
> you send through your SceneBuilder files to play with?
>
I can absolutely share. Do you want just the FXML files? I still have
re-factoring work to do (the ObjEntity tab views are all in one FXML file
currently, and I want to split it out into separate view files/controllers,
for example -- one controller/view per tab), so I'm expecting them to
change quite a bit. My hope is that sometime next week I'll have it
cleaned up enough to share all of it (Java, READMEs, etc). Keep in mind
this is very much a prototype/hack and I'm learning JavaFX as I go (only
spent ~4 days on it so far).
I think the other problem to solve is the icons. Myself, I typically use
> Cayenne Modeler once every few months. So every time I use it, I'm clicking
> on icons to try and remember which one is which. Is blob-blob-plus a new
> relationship?
>
Tooltips are required for all of these. Even when I've "lived" in CM, I
still used the tooltips a lot...
Re: Cayenne Modeler Prototype
Posted by Michael Gentry <bl...@gmail.com>.
On Tue, Mar 29, 2016 at 12:55 AM, Aristedes Maniatis <ar...@maniatis.org>
wrote:
> Your icons are much more consistent than what we have today, even though
> they aren't terribly informative visually.
>
I'm using this library for the icons (fonts):
https://bitbucket.org/Jerady/fontawesomefx
Currently they are mostly from FontAwesome, but easy to choose one of the
other icons from a different font package.
mrg
Re: Cayenne Modeler Prototype
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 29/03/2016 7:06am, Michael Gentry wrote:
> One thing I'm curious about is with the 4.0 CM, the
> attributes/relationships tabs have been merged. With the approach I was
> taking, keeping them separate allowed an "inspector" to appear below the
> the attributes (I was going to take the same approach for relationships) so
> that you don't have to deal with a popup inspector. I think this is very
> useful when adding the JavaDoc and Annotations support. Having the
> inspector there obviously takes up valuable screen space, so I'm concerned
> that if the attributes and relationships remain merged, as in the 4.0 CM,
> the display area would be quite tight. Maybe we should keep them separate?
>
> I've spent 3-4 days on it thus far, but would love some constructive
> feedback, especially if I'm heading down a bad path.
Visually, it looks much improved, and the JavaFX skin is clean and modern. Your icons are much more consistent than what we have today, even though they aren't terribly informative visually.
I can see what you are doing with the "inspector" however I don't think the hierarchy of information is very clear. That is, a user can understand the left tree shows DataDomain -> DataMap -> ObjEntity. And then they are shown a list of attributes and other properties of that ObjEntity in the right panel when they click in the tree.
It is also clear that each of those properties (eg an attribute or relation) has a number of 'options' they can adjust, displayed in columns: name, Java type, path, etc.
However I think it becomes confusing to then show additional options in a panel at the bottom: annotations, docs, etc.
Possible solutions:
1. Move ObjEntity properties into the tree on the left. For an example of such an approach (from MySQL Workbench) look at this:
https://dl.dropboxusercontent.com/u/14832257/tree%20with%20attributes.png
Pros:
* The overall structure is clearer
* Plenty of room in the right panel to clearly set out Java type, DB type, locking, and the other options now shown in the table. This gives more room for clearer labels and help text.
* No more editing in tables which can be non-intuitive if you don't know where to click
* More easily expandable compared to what we have today
* Easier to show validation errors (it can be hard to style table cells to show errors)
* Existing floating windows like the "relationship inspector" now has enough room to fit in the edit view.
Cons
* List of attributes sorted only by name, with callbacks, attributes and relations all mixed (probably with different icons to distinguish them). Although the mysql example does separately group columns/indexes/etc so they could be kept separated.
* More clicks to rapidly change options of lots of attributes (click on each, then change property in right panel). Is this a common use-case?
* You don't see all the attributes with their options in a table in one glance
2. A three panel view. So, Michael's design but with the additional properties to the right rather than at the bottom.
This sort of approach is common in email. Tree of mailboxes to the left. List of messages in the middle and the details to the right. We'd have domain/map/objentities in the left tree. Attributes in the middle. Options to the right.
Pros:
* Left tree is simpler than in option 1
* Shows hierarchy better than option 0 (Michael's mockup)
Cons
* Middle panel (list of attributes) would need to have fewer columns than we do now in order to keep the width to a minimum.
* Not as flexible as option 1
* combination of tree and multi-panel approach might be confusing
3. Move the additional options (javadoc, annotations, etc) into floating windows like the Relationship Inspector.
Pros:
* Least effort
* Yeah, nothing else.. its a pretty horrible UI choice.
Cons:
* Ugh
I had a quick go at mocking some of these up, but spent so much time fighting the tools that I didn't get very far. Michael, if convenient can you send through your SceneBuilder files to play with?
I think the other problem to solve is the icons. Myself, I typically use Cayenne Modeler once every few months. So every time I use it, I'm clicking on icons to try and remember which one is which. Is blob-blob-plus a new relationship?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A