Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ajdt-dev] RE: [Bug 80094] Cross reference view (and inplace view)

Hi Matt,

You make some very good points that I think are of general relevance to AJDT
development, so I'm moving the discussion to the list.  

I agree with your approach and have always considered it as the only way to
properly support Eclipse.  The replaced Outline view is a relic of the
JBuilder and NetBeans support, from when that integration strategy made
sense.  A lot has changed since then.  To be compatible all the features an
Eclipse programmer expects have to work (e.g. drag-and-drop refactoring).
But it is still crucial to stick to the mantra: 

   Wherever the programmer sees OOP structure, they see the corresponding 
   AOP structure and can conveniently navigate to where it is declared.

So if they're looking at a method in some view, they can see an indication
of advice on that method and navigate to that advice.  If they see a type
hierarchy they can tell which supertypes have been added and navigate to the
corresponding "declare parents".  We have the following ways of extending an
existing view/editor to expose the crosscutting:

1) Using defined extension mechanisms, either via plugin.xml or code.  
2) Subclassing and controlling the instantiation and lifecycle.
3) Replacing the view and replicating the functionality.

(1) is great when it works, and it does for adding new decorators for Java
elements.  From my experience (2) is possible for the Package Explorer, java
source and bytecode editors, Problems List, and barely so for the Document
Outline.  (3) is our current Outline and as you indicate a problematic
strategy and should be avoided.

Now there's the question of what strategy to use given the requirements.  If
the main use of the cross reference view is to make the programmer aware of
whether or not there is crosscutting, then using (1) and making it easy to
pop up the inline cross reference will work well.  Because the Outline view
is used very frequently by typical programmers (the Mylar study indicated
this to my surprise), the cross reference view may also need to be
accessible via context menu on the Outline, and perhaps in any context menu
of a view that shows Java elements.  

From the screenshots on the bug report it looks like you may be considering
the cross reference view as duplicating the current Outline functionality,
where the user wants to see and navigate the crosscutting for all the
members of class.  If this is the common use case then the cross reference
view is really just an Outline view with additional links inserted.  And it
should look consistent as an inline view as well as an anchored view.  In
this case strategy (2) for extending the Outline is probably better, and a
button for filtering the visibility of the relationships should make it easy
to toggle between having it look identical to the JDT's and showing the
crosscutting.  

Also, I'll voice my concern a final time about why calling it the "cross
reference" view may not be ideal.  It's a generic name, and a somewhat
inaccurate one.  The driving use case is for navigating from shadows
affected by aspects to an aspect's member declarations.  Those shadows do
not "reference" aspects--they're not like method calls that reference
methods.  It's even a stretch to say that the pointcuts in the aspects
"reference" the shadows, because the references are often indirect (e.g. via
type patterns and wildcards).  The genericity can be good if you also want
to use it for solving the problems of showing OOP or domain-specific
structure (e.g. showing "overrides", "unit tests", or "ejb remote
references").  But supporting this genericity will inherently make it a less
obvious UI for working with AspectJ.  So consider explicitly limiting it to
showing crosscutting, and calling it the "Crosscutting view".

It's great that you're putting all this thought and effort into the AJDT UI
Matt.  In my mind smoother integration and that makes the crosscutting
structure more clear is essential to further AJDT adoption.
 
Mik

> -----Original Message-----
> From: Matt Chapman [mailto:MCHAPMAN@xxxxxxxxxx]
> Sent: Sunday, December 12, 2004 2:07 PM
> To: beatmik@xxxxxxx
> Cc: Helen Hawkins; Julie Waterhouse
> Subject: Fw: [Bug 80094] Cross reference view (and inplace view)
> 
> Hi Mik,
> 
> Firstly, the xref view and the advice decorator are both in the build, and
> the latest version should be working reasonably well.
> 
> You make a good point about the duplication, but there's some thought
> behind all of these changes which I don't think I've communicated clearly
> before. The main issue here is about making AJDT "play nicely" with the
> rest of Eclipse, and other third party plugins, and not do anything
> disruptive to the rest of the platform. One case of this is with the
> suggestion that our custom editor is used for all .java files. Many users
> are uncomfortable with doing this, particularly as our editor has
> traditionally lacked various capabilities of the Java editor. But of
> course if they don't do this, they lose major functionality: the advice
> markers in the gutter, and the relationships in the outline view. There is
> also a similar issue with the current outline view, which is lacking
> capabilities of the Java outline view, such as the context menu. We are
> therefore working towards an alternative model where all, or equivalent,
> functionality is available using the standard Java editor and Java outline
> view (with the AJ editor just for .aj files). We are delivering on most of
> this for M2 - the markers are there, and the Java outline view picks up
> the advice decorator (btw that decorator was a good suggestion, which
> helps bring all this together) to show which methods are advised, with the
> full relationships being shown in the new xref view (with an in-place
> version of this to come in the future). This setup will be the default,
> with preference settings to get back to the old arrangement if desired.
> The advice decorator shows up in all these views - the Java outline view,
> the xref view, the package explorer, and the members view in the browsing
> perspective etc.
> 
> Regards,
> 
> Matt.
> 
> > ------- Additional Comments From beatmik@xxxxxxx  2004-12-09 10:00
> -------
> > Hi Helen,
> >
> > The main thing that I'm noticing is that the "cross references"
> viewseems to
> > be identical to the Document Outline, if the Outline were givin the
> > "limit to"
> > functionality that the default Eclipse tree views have (forward arrow
> that
> > allows you to only see the current tree as children).  So should these
> not be
> > the same component?  That's one of the things that works so nicely with
> the
> > JDT--the Outline view is the same as the inline outline, etc.  The
> following
> > could be different instances of an outline view, with different
> filterings on
> > by default:
> >
> > * Document Outline
> >   - all relationships filtered by default
> >
> > * Inline references
> >   - focused in on currently-selected element
> >   - all reationships visible by default (e.g. uses pointcut)
> >
> > * Cross references
> >   - Same as cross references
> >
> > This would result in consisntency between the icons and views, which I
> think
> > is very important (e.g. Matt's new advice decorator would show up
> > everywhere).



Back to the top