| RE: [ajdt-dev] AspectJ Perspective? |
|
I’d argue that in an AspectJ project, you
want to see the AspectJ type system, i.e., when you hit Ctrl+Shift+T, you
expect to see all your types including AspectJ types. When you hit F4 you
expect to see a type hierarchy that understands AspectJ too… Indeed, I’d like
to have project-based bindings but Eclipse doesn’t appear to have that as a way
of assigning keys… For reporting missing F3 functionality I’ll
try to package a small project that can be referenced in a series of bug
reports… From:
ajdt-dev-bounces@xxxxxxxxxxx [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Matt Chapman One problem with
assigning key bindings is that so many are already taken! And who is to say
some other plugin isn't going to contribute a conflicting binding. But having
the same binding do different things in different perspectives may also be a
bit confusing. On 18/07/06, Ron
Bodkin <rbodkin@xxxxxxxxxxxxxx>
wrote: Ok: I see how you can rebind key sequences in Eclipse. It's
good to be able to do this and to know that there is an existing binding. Maybe
what would be more valuable would be an easy way to enable natural AspectJ
keyboard bindings. However, I believe that having a new perspective would be
the natural way to do this. I definitely like having Ctrl+Shift+T open aspect
types. F3 works within an aspect for me for types, methods, and
pointcuts. However, there are several other cases where I'd like it to work. I
believe that making it work for these will require binding to an
AspectJ-specific command. Here are some cases I found with a little testing in
my code, where F3 doesn't work:
I can raise bugs for these if you like… E.g., public aspect StatsJmxManagement { public static class
PerfStatsBeanImpl implements DynamicMBean { …
private static CompositeType makeChildRowType() {
return new CompositeType(PerfStatsImpl.class .getName(), … // F3 on PerfStatsImpl fails
} … } public Object PerfStatsImpl.getMBean() { // F3 on
PerfStatsImpl jumps to aspect
try {
if
(!useCompositeBean) {
return getDefaultMBean();
// ITD method – F3 fails
}
String operationName = getOperationName();
if (operationName
== null ) {
logWarn("Unexpected
null bean for operation: " + operationName);
return null ;
}
return new PerfStatsBeanImpl( this , operationName); // F3 on type works here … // F3 on ManagedBean
fails in both cases and it fails on getDefaultMBean too declare error: call(*
ManagedBean.getDefaultMBean()) && ! withincode (* ManagedBean+.*(..)): … From: ajdt-dev-bounces@xxxxxxxxxxx
[mailto: ajdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Matt Chapman
F3 already works in some cases, e.g. types in .aj
files and for pointcuts. It might be possible to get the other cases working
via the standard F3 support, without having to override it. On
17/07/06, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx>
wrote: I think this perspective could usefully remap some other keys
into their AspectJ type-aware equivalent (e.g., F3 to look up an
AspectJ-defined type or a method in one or an ITD). I'm assuming that it's not
possible to It could also show buttons only for the AspectJ version (e.g.,
remove the open Java type button and only show the AspectJ one). Of course if a
perspective like this is popular, it would lead to demand for AspectJ Browsing
and AspectJ Debug perspectives… I would definitely prefer to have all this
functionality in the Java perspective if it were possible. Maybe a fallback position for the keyboard bindings would be
to define a new set of bindings. Does Eclipse allow a plugin to bind new key
sequences in existing perspectives? From: ajdt-dev-bounces@xxxxxxxxxxx
[mailto:ajdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Matt Chapman
Subject: Re: [ajdt-dev] AspectJ
Perspective? This is an interesting issue. If implemented, it
wouldn't stop anything that works today from working - users could continue to
use the Java perspective for AspectJ development, just as I use the Java
perspective for plug-in development, instead of the Plug-in Development
perspective. Perspectives are little more than a layout of views and as eclipse
users are already familiar with this concept, I think adding an new perspective
as an "optional extra" has a fairly low risk of causing confusion.
The other question is of course what could be gained from such a new
perspective. I can only think of the things already mentioned, a layout of the
2 AJDT views, and providing a key binding for Ctrl-Shift-T to open AspectJ type
instead of open Java type. I'd say it's debatable whether this is worth the
implementation cost, as the new perspective would have to contribute everything
the Java one does (and keep this up-to-date as the Java one changes over time).
Does anyone have any thoughts as to what else such a perspective could offer? On
17/07/06, Matthew Webster <matthew_webster@xxxxxxxxxx
> wrote:
Matthew
Webster
|