RE: [ui-best-practices-working-group] Annotation and XML configurationdi

["Troy Beecroft" <troyb@xxxxxxx>]

Hi Neil,

One of the points you raised was:

>>We want to be consistent with the platform (have an 
>>editor for XML files), but this will cause our UI editing experience 
>>between Java and XML to be somewhat inconsistent.

This may be an inconsistency that has little practical impact.  I wonder
if very many people will use both the annotations approach and the XML
approach.  Seems more likely that most users will deal with only one
approach or the other, but not both.  If so then using a prop sheet for
one and a more typical XML editor for the other may be fine.

Re: the general issues of editing Java annotations, using the tabbed
properties view seems like a very natural fit. Hopefully the current
limitations you mentioned won't prove insurmountable.  Solving those
issues could have very general payoff for future consumers of the tabbed
properties view as well as the Java editor.

-Troy 


-----Original Message-----
From: ui-best-practices-working-group-bounces@xxxxxxxxxxx
[mailto:ui-best-practices-working-group-bounces@xxxxxxxxxxx] On Behalf
Of Neil Hauge
Sent: Wednesday, November 08, 2006 4:43 PM
To: User Interface Architecture Working Group
Subject: [ui-best-practices-working-group] Annotation and XML
configurationdiscussion (WTP-JPA Dali Tools)

As mentioned on the call earlier today, I would like to discuss a 
current UI direction/best practice issue with the group related to 
annotation and XML configuration.  We have touched on this issue briefly

in the past, but our project is currently trying to decide what 
direction to pursue and needs to determine the correct direction as soon

as possible.  Guru has agreed to switch presentation dates with me, so I

think we have everyone's agreement that we'll do the TPTP Show and Tell 
on Dec 6th, and the Dali/Webtools JPA  S&T on November 22nd.  Let's get 
things started with an email discussion and go from there.

Here is basic problem.  In the WTP-JPA Dali Tools, we need to assist the

user with configuring the persistence of their object model.  This can 
be a fairly complicated task, especially for large and complex object 
models.  With the introduction of EJB 3.0, users can choose to configure

persistence via Java source annotations and XML descriptors 
(persistence.xml), or solely by using XML descriptors(orm.xml and 
persistence.xml). It's not really important to understand what the files

are and what they do, it's only important to understand that there are 2

different ways to configure the same meta data in different artifacts, 
and this needs to be handled in some way in the UI..  *See enhancement 
request 154781 for more information on the question of how we should 
deal with annotation based configuration in the UI - 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154781.

So, in our tooling we must support a very similar configuration ability 
in two very different artifacts (Java classes and XML).  In our initial 
approach to this problem, we thought it would be advantageous to the 
user and to us to have a consistent approach to configuring these 
artifacts.  We accomplished this by creating our own Persistence 
Properties View which served as a rich UI that stayed in sync with the 
Java Editor.  We are also using this view with the orm.xml file, 
providing a similar experience in configuring the persistence 
properties, regardless of where they are being configured.  When you are

editing an annotated Java class, you see the persistence properties for 
that class, and changes you make in the PersistencePropertiesView change

the state of the annotations in that class file.  When you are editing 
the orm.xml file, you see the persistence properties for that XML 
descriptor, and changes you make in the PersistencePropertiesView change

the state of the xml content in that xml file.  (As a side note, we also

plan to support in-Java-source annotation value code completion and 
in-xml-source completion).

What are the high level problems with this approach?  1. We are using 
our own properties view, while the platform already has a generic Tabbed

Properties View (as of 3.3) 2. We are using a properties view to 
configure an XML descriptor.  A more standard approach would be to have 
an XML editor for editing an XML file (such as the plugin.xml editor).  
So what are the problems with solving those problems?  1. The 
TabbedProperties are not enabled for the Java editor (bug 154781).  It 
also can only have one true contributor (bug 158607), so different 
plugins from different domains would have a hard time using the standard

TabbedProperties for a generic editor like the Java Editor.  2. As for 
the editor for the orm.xml file, this removes the consistency with the 
"properties" based solution for both artifacts. 

In summary, we have several different options at this point.  We want to

be integrated with the platform, but this is proving to be difficult 
given the current limitations of TabbedProperties (there are more that I

haven't mentioned).  We want to be consistent with the platform (have an

editor for XML files), but this will cause our UI editing experience 
between Java and XML to be somewhat inconsistent.

What I am looking for here is some discussion around what is best for 
Eclipse, our extenders, and our users, given our current situation.  I 
think the decision we make here will likely have an impact on future 
groups who end up in the same position, as annotation usage become more 
and more prevalent.

Thanks for any input,
Neil


Neil Hauge
WTP-Dali JPA Tools Lead
Oracle TopLink Tools


_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.