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:
- Aspect
type used in Java class (even with .aj extension)
- Method
defined in aspect type used in Java class
- ITD
used in Java class or aspect
- Type
declaring an ITD for inner interface defined in an aspect (it jumps to the
top-level aspect, not the nested type). It does work in the ITD
implementation body (*)
- ITD
method used inside ITD in an aspect
- Inner
type used inside itself
- Type
used inside type pattern or method signature
- Method
used in method signature
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
Sent: Tuesday, July 18, 2006 4:21
AM
To: AspectJ
Development Tools developer discussions
Subject: Re: [ajdt-dev] AspectJ
Perspective?
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.
Yes, you can bind new key sequences - we already do. Alt-Shift-A is "Open
AspectJ Type". You could of course manually reconfigure this to
Ctrl-Shift-T if you're used to that combination from Open Java Type.
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?
To: AspectJ Development Tools developer discussions
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?
Regards,
Matt.
Matt,
I think we tried this with early versions of AJDT. One problem is that
it emphasizes the difference between Java and AspectJ; something we are trying
to avoid. Also might user's get confused if for some reason they switch back to
the Java perspective or start using one of the other special ones like plug-in
or web development?
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM
Hursley Park,
Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
Hi
Ron,
That has occurred to me also. It could include the
Cross References
and Crosscutting Comparison views in its layout.
People could of
course continue to use the Java development
perspective if they
preferred, but this would offer an alternative.
Regards,
Matt.
On 14/07/06, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx>
wrote:
> I was thinking about how to remedy some of
the limitations for AspectJ
> support in Eclipse like the ctrl+shift+t (and
f3?) keyboard bindings that
> use the Java type system rather than the
AspectJ one. It occurred to me that
> it might be possible to get a lot better
support (e.g., new key bindings,
> show only the AJ type button by default etc.)
with an AspectJ *perspective*
> in Eclipse. Am I just being optimistic here,
or would that be a way to
> improve usability of AJDT?
>
>
>
> Thanks,
>
> Ron
>
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
>
>
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev