Meeting summary: We have a concrete direction for the UI.
- We agreed that option 3 from the meeting would be the best choice
for our current requirements and constraints. This option consisted of
a logical "JPA Structure" view for navigation/information and a "JPA
Details" view for configuration. These two views would be used for
both Java source annotation and orm.xml configuration and would be
similar in content where applicable.
- The Structure and Details views would make up the core of the
Dali Tools UI, along with the persistence.xml editor. An editor for
orm.xml would be highly desirable, and would consist of top-level
orm.xml configuration and/or a summary view of the project. Top-level
configuration would consist of Add/Remove functionality for elements
such as Entities, Embeddables, Mapped Superclass, Attributes, and
perhaps Queries and Generators, etc.
- As a result of adopting the "Structure/Details" views, we will no
longer need to rely on the Tabbed Properties functionality.
- It may be desirable to include Entity-Mappings and Entity level
sub-elements (such as named queries) into the Structure tree. Tabs
would still need to exist for these items in the Details view, but
nodes in the tree could simply focus selection in the Details.
- The standard Outlines for the Java and XML editor will deal with
physical attributes of the file being edited. Our "JPA Structure" will
be a logical view that may include elements that are not present in the
file, such as Java attributes that have not been overridden in the
orm.xml when viewing the orm.xml.
- For now, persistent type ordering will be handled by appending
new elements at the end of their respective list. In the future, we
may want to add the ability for the user to manage order, or make order
preference based, with the ability to keep elements sorted.
Let me know if I forgot anything major, or if anyone disagrees with the
content.
Neil
Neil Hauge wrote:
Meeting: Dali 1.0 UI Design meeting
Time: Friday, December 15th, 11:00am - 12:30pm (16:00UTC)
Web conference: ID- 63921343 -
http://conference.oracle.com
Agenda: Present and review final UI proposals and determine which
proposal to implement
Details: There are still two basic approaches that we are currently
reviewing, as noted in the email below. Let me know if you have any
questions.
Neil
Neil Hauge wrote:
There has been much discussion recently on the UI direction for Dali
1.0. Here is a recap of things we have talked about over the past week
or so.
- We should still take advantage of the Project Explorer for
the
total picture, JPA project view
- If possible, we should take advantage of the root node
interrogation to determine the content type of an XML file. The EMF
XML translator
appears to have a bug which prevents this usage. A bug has been filed
to correct this problem.
- We have generally agreed that we would like to use properties
to
edit annotations. We have somewhat agreed that using properties for
editing orm.xml is also a good way to go, and has advantages in the UI
consistency department. An editor and outline could be used in this
arrangement with the properties.
- Paul introduced a new idea which could greatly simplify our
complete UI story, and also provide consistency between annotation and
orm.xml editing. This idea includes moving the persistence navigation
from the persistence outline into the properties (or even tabbed
properties), where the persistence navigation is really a tree
representing the structure of an entity. This tree would be located on
the left side of the properties pane and would drive the UI content in
the properties. This removes the need for a
second outline view in the annotation editing case. It also makes it
easier for us to
use Tabbed Properties, since all of the UI would be reachable through
one "JPA" tab. On the XML side there would be a similar Entity
structure
tree inside of the properties. We could choose to just use the tabbed
properties to display our Entity properties for the XML Editor, or we
could
choose to create our own Editor and Outline, used primarily for Entity
navigation. The structure tree could display the merged, quick-view of
an Entity while viewing XML -or- the merged view could be in our own
orm.xml
editor/outline if we were to create one. With this strategy, we
wouldn't need
to have any "custom" views. Everything could be done using platform
components. See attached PropertiesStructureTreeConcept.jpg as a
rough example of the XML case.
I think at this point we have 2 main proposals on the table.
One that would involve keeping our current Dali views along with a new
Editor arrangment for XML, and the properties
structure tree concept. This new concept addresses several drawbacks
in the earlier plan, including removing inconsistencies between Java
and XML, allowing us more easily use tabbed properties in its current
state, and
addressing real estate concerns in the properties. The main drawback
to this new concept is that tree based properties navigation would be
in a
fairly small vertical space.
Neil
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
|
