Home » Language IDEs » AspectJ » search function design
| search function design [message #4267] |
Thu, 19 September 2002 01:35  |
 Julie Waterhouse
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi all,
I'm in the preliminary stages of implementing an AspectJ search facility
for ajdt. Following are some design ideas, thoughts and questions to the
user community - feedback is encouraged.
Search will be implemented as a new "AspectJ" page on the existing search
dialog. I would expect it to behave in a similar manner to the Java
Search page. There should be an entry field for text to search, which
will accept wildcard searches. There should be a "case-sensitive"
checkbox. There should be a set of things you can search for (see below),
and the ability to restrict the search in appropriate ways (see below).
You should also be able to restrict the scope of the search to workspace,
selected resources or working set.
I have included a link to a screen capture of a first pass at the search
dialog. Note that this is something I threw together quickly, and I
recongise that it's less than ideal. I include it here to better
illustrate the following discussion. Input on the GUI is welcome, as it
definitely needs more thought, but I think the design of how the search
works must come first.
Screen capture: http://members.rogers.com/30159374290/searchpage.html
Reminder: on the Java search page, you can search for
-type
-constructor
-method
-field
-package
and limit your search to:
-declarations (applies to all)
-references (applies to all)
-implementers (currently disabled, intended for interfaces)
-all occurrences (applies to all)
-read access (applies to fields)
-write access (applies to fields)
For the AspectJ search,
The search for/limit to paradigm used by the Java search doesn't seem to
hold up for AspectJ. In many cases (discussed below), you want to search
for constructs (like advice or pointcuts) that affect a particular
class/method/field (rather than searching for a subset of occurrences of a
particular class/method/field).
What should you be able to search for? Possibilities include:
(a) aspects
(b) pointcuts
(c) advice
(d) introductions
(e) warnings and errors
(f) softened exceptions
(g) other?
Let's look at the issues with each of these in turn, in particular with
how it might be appropriate to limit the search in each case:
(a) aspects
-Certainly it makes sense to search for declarations of an aspect. Are
there any search limits that make sense here?
(b) pointcuts
-This was the trickiest one to get my mind around...
-You should have the ability to search for named pointcut declarations.
Are there any search limits that make sense here?
-What about all pointcuts that pick out join points in a particular type
or method? Here, you might specify that you're searching for a pointcut,
and then restrict the search to find only those pointcuts that pick out
join points in a named class/method/field. Does this make sense? Is it
useful? What about the primitive pointcuts used in advice - in that case,
there's no explicit pointcut definition to return from a search - rather,
we might find the advice that affects the named class/method/field (case
(c) below). Is a search for named pointcuts, plus case (c) all that's
useful, or is there something else lurking in here?
(c) advice
-I wouldn't think you'd want to search for all "before" advice, or all
"after" advice etc. More likely you'd want to search for all advice that
affects a particular class/method/field. In that case, it may again make
more sense to search for advice and restrict the search to find only
advice affecting a named class or method (this is the example illustrated
by the screen capture).
(d) introductions
-Again, this would seem to work like advice where you would want to search
for introductions, and restrict to those introductions affecting a named
class (method/field don't seem to apply here).
-Should a search for introductions find "declare parents" in the results
as well as member introductions? Would these be better separated into two
categories?
(e) warnings and errors ("declare error", "declare warning")
-Would you want to search for these? One category or two? What kind of
restrictions might make sense?
(f) softened exceptions ("declare soft")
-Would you want to search for these? What kind of restrictions might make
sense?
(g) other
-Now that aspectJ will be built on the eclipse compiler, some things will
come to us for "free". A search for implementers on the Java Search page
(once enabled), would also return aspects in the result set. Would it be
useful to have an "implementers" search on the AspectJ search page that
returned only aspects that implement a specified interface?
-Is there anything I've missed that would be useful to search for?
Should the final GUI resemble anything similar to the included screenshot,
I would expect at a minimum that the "Named" and/or "Affecting + Named"
sections will be enabled/disabled as appropriate for each different type
of search. Examples: (1) if "Advice" is chosen in the "Search for"
section, the first "Named" will be disabled. (2) if Aspect is chosen,
"Named" would be disabled, and the "Affecting" + "Named" pair would be
enabled. (3) if "Pointcut is chosen, all would remain enabled.
Comments and feedback most welcome.
Regards,
Julie Waterhouse
AJDT Development Team
|
|
|
| Re: search function design [message #4341 is a reply to message #4267] |
Thu, 19 September 2002 09:03  |
Eclipse User |
|
|
|
Originally posted by: Arno Schmidmeier.sirius-eos.com
Hi Julie,
Hi all,
As Aspects can implement an interface and aspects can be subclasses from
standard java-classes. So aspects can play the role of standard java
objects.
And users will use aspects also in this way, as soon as the experience
with aspects increases.
So the dialog needs "all" the search functionality of plain java.
IMHO it is educational mistake to separate the search functionality in
plain java and in aspectJ specific elements. Both of these dialogs/panel
should be closely tied together.
IMHO the body of advices should be as small as possible, because advices
can currently not be adviced. But extracted methods from an advice can be
adviced.
So aspects of experienced aspectJ programmers have quite a buch of methods.
Aspects tend to look like standard classes, with some pointcuts and
advices in them.
A very important search functionality is searching after "conflicts",
"unkown" pointcuts, and advices affecting, influencing and intercepting
code. I am aware that these search case are not very often performed in
standard java.
Additionally I added some comments below:
Hope these comments help.
I appreciate any comments on mine, too!!!!
As they help me understand how other users work with IDEs in
aspectJ-programs!!!
regards
Arno Schmidmeier
Chief Scientist
Sirius Software Gmbh
Julie Waterhouse wrote:
> Hi all,
> I'm in the preliminary stages of implementing an AspectJ search facility
> for ajdt. Following are some design ideas, thoughts and questions to the
> user community - feedback is encouraged.
> Search will be implemented as a new "AspectJ" page on the existing search
> dialog. I would expect it to behave in a similar manner to the Java
> Search page. There should be an entry field for text to search, which
> will accept wildcard searches. There should be a "case-sensitive"
> checkbox. There should be a set of things you can search for (see below),
> and the ability to restrict the search in appropriate ways (see below).
> You should also be able to restrict the scope of the search to workspace,
> selected resources or working set.
> I have included a link to a screen capture of a first pass at the search
> dialog. Note that this is something I threw together quickly, and I
> recongise that it's less than ideal. I include it here to better
> illustrate the following discussion. Input on the GUI is welcome, as it
> definitely needs more thought, but I think the design of how the search
> works must come first.
> Screen capture: http://members.rogers.com/30159374290/searchpage.html
> Reminder: on the Java search page, you can search for
> -type
> -constructor
> -method
> -field
> -package
> and limit your search to:
> -declarations (applies to all)
> -references (applies to all)
> -implementers (currently disabled, intended for interfaces)
> -all occurrences (applies to all)
> -read access (applies to fields)
> -write access (applies to fields)
> For the AspectJ search,
> The search for/limit to paradigm used by the Java search doesn't seem to
> hold up for AspectJ. In many cases (discussed below), you want to search
> for constructs (like advice or pointcuts) that affect a particular
> class/method/field (rather than searching for a subset of occurrences of a
> particular class/method/field).
> What should you be able to search for? Possibilities include:
> (a) aspects
> (b) pointcuts
> (c) advice
> (d) introductions
> (e) warnings and errors
> (f) softened exceptions
> (g) other?
* plus add the elements
> -type
> -constructor
> -method
> -field
> -package
from java. where type equals class and aspect!!! So you can drop then the
search aspect option from the list, if the search type option is available.
> Let's look at the issues with each of these in turn, in particular with
> how it might be appropriate to limit the search in each case:
> (a) aspects
> -Certainly it makes sense to search for declarations of an aspect. Are
> there any search limits that make sense here?
see above
> (b) pointcuts
> -This was the trickiest one to get my mind around...
> -You should have the ability to search for named pointcut declarations.
> Are there any search limits that make sense here?
> -What about all pointcuts that pick out join points in a particular type
> or method? Here, you might specify that you're searching for a pointcut,
> and then restrict the search to find only those pointcuts that pick out
> join points in a named class/method/field. Does this make sense? Is it
> useful? What about the primitive pointcuts used in advice - in that case,
> there's no explicit pointcut definition to return from a search - rather,
> we might find the advice that affects the named class/method/field (case
> (c) below). Is a search for named pointcuts, plus case (c) all that's
> useful, or is there something else lurking in here?
I agree searching with pointcuts is the most trickiest element.
And that is the point, where a developer needs as much support from the
tools as possible. I will describe in short the optimal search-use cases
for pointcuts, I have seen in my work, and by observing some other aspectJ
developers.
1. I select a block of code, enter the search dialog, and get a list of
all pointcuts (named/unnamed), who define joinpoints for this type of
block of code.
2. I select a pointcut, enter the search dialog and get a list of all
pointcuts , who have joinpoints (named/unnamed) with this pointcut in
common.
> (c) advice
> -I wouldn't think you'd want to search for all "before" advice, or all
> "after" advice etc. More likely you'd want to search for all advice that
> affects a particular class/method/field. In that case, it may again make
> more sense to search for advice and restrict the search to find only
> advice affecting a named class or method (this is the example illustrated
> by the screen capture).
I agree with you that simple search for before advices, or all after
advices is not very likely. Your use case is quite realistic.
Based on my experience I see there a much more important use case, which
is:
Which advices of a conflicting type advices the same joinpoints. (whithout
having a dominates subordinates relationship)
this search can be narrowed, by specific types, by selecting a given
advice.
Also I want to search after advices, which directly or indirectly (through
pointcut composition) use (or are affected, e.g. some pointcuts are
excluded through &&!) by a given pointcut.
> (d) introductions
> -Again, this would seem to work like advice where you would want to search
> for introductions, and restrict to those introductions affecting a named
> class (method/field don't seem to apply here).
> -Should a search for introductions find "declare parents" in the results
> as well as member introductions? Would these be better separated into two
> categories?
it must find it!
Also indirect introduction should be found. (e.g. container introduction)
E.g. introducing a method to an interface, and introducing this interface
to a class, aspect, etc.
> (e) warnings and errors ("declare error", "declare warning")
> -Would you want to search for these? One category or two? What kind of
> restrictions might make sense?
Quite likely, but not necessarily.
> (f) softened exceptions ("declare soft")
> -Would you want to search for these? What kind of restrictions might make
> sense?
Yes
> (g) other
> -Now that aspectJ will be built on the eclipse compiler, some things will
> come to us for "free". A search for implementers on the Java Search page
> (once enabled), would also return aspects in the result set. Would it be
> useful to have an "implementers" search on the AspectJ search page that
> returned only aspects that implement a specified interface?
> -Is there anything I've missed that would be useful to search for?
> Should the final GUI resemble anything similar to the included screenshot,
> I would expect at a minimum that the "Named" and/or "Affecting + Named"
> sections will be enabled/disabled as appropriate for each different type
> of search. Examples: (1) if "Advice" is chosen in the "Search for"
> section, the first "Named" will be disabled. (2) if Aspect is chosen,
> "Named" would be disabled, and the "Affecting" + "Named" pair would be
> enabled. (3) if "Pointcut is chosen, all would remain enabled.
> Comments and feedback most welcome.
> Regards,
> Julie Waterhouse
> AJDT Development Team
|
|
|
| Re: search function design [message #4964 is a reply to message #4341] |
Thu, 03 October 2002 14:47 |
Julie Waterhouse
Messages: 42
Registered: July 2009 |
Member |
|
|
First of all, Arno, I want to apologise for taking so long to reply to
your post - things have been a little crazy recently! Second, I want to
thank you for your thoughtful reply and suggestions.
Some thoughts in response...
You suggest adding the elements "type, constructor, method, field and
package" to the AspectJ search page. This brings up the issue of how we
separate functionality between the AspectJ search page and the Java search
page in the search dialog. Since search for those items already exists on
the Java search page, I would propose leaving them there. However, since
we will soon be based on the Eclipse compiler, a search for a "type"
should then also return aspects as well. So the Java page will have the
ability to search for at least that AspectJ-related object. That means
the line is a little blurred between the two pages. What do people think
is the right solution? Do we repeat an aspect-only search on the AspectJ
page? Or do we keep all type searching together in one place only on the
Java page?
Regarding your comments on searching for pointcuts, in your first use
case, you suggest selecting a block of code and searching for pointcuts
that pick out join points in that block (if I read it right). Mik, can
you comment on the feasibility of selecting a block of code to search in
this way? If that's not possible, is it easier to specify a particular
type, method, or field and search for pointcuts that affect it? (should
achieve almost the same function (not quite as specific), with a different
UI).
Your second pointcut use case is interesting (searching for all pointcuts
that share join points with a specified pointcut, again, if I'm reading
you right). Mik, can you comment on the feasibility of implementing this
one from an AspectJ perspective?
I encourage others to contribute to this discussion as well. As the users
of AspectJ in Eclipse, you know best what search functionality would be
most useful to you, and you have an opportunity to influence the design.
And I promise to be much quicker to respond next time!
Regards,
Julie Waterhouse
AJDT Development Team
Arno Schmidmeier wrote:
> Hi Julie,
> Hi all,
> As Aspects can implement an interface and aspects can be subclasses from
> standard java-classes. So aspects can play the role of standard java
> objects.
> And users will use aspects also in this way, as soon as the experience
> with aspects increases.
> So the dialog needs "all" the search functionality of plain java.
> IMHO it is educational mistake to separate the search functionality in
> plain java and in aspectJ specific elements. Both of these dialogs/panel
> should be closely tied together.
> IMHO the body of advices should be as small as possible, because advices
> can currently not be adviced. But extracted methods from an advice can be
> adviced.
> So aspects of experienced aspectJ programmers have quite a buch of methods.
> Aspects tend to look like standard classes, with some pointcuts and
> advices in them.
> A very important search functionality is searching after "conflicts",
> "unkown" pointcuts, and advices affecting, influencing and intercepting
> code. I am aware that these search case are not very often performed in
> standard java.
> Additionally I added some comments below:
> Hope these comments help.
> I appreciate any comments on mine, too!!!!
> As they help me understand how other users work with IDEs in
> aspectJ-programs!!!
> regards
> Arno Schmidmeier
> Chief Scientist
> Sirius Software Gmbh
> Julie Waterhouse wrote:
> > Hi all,
> > I'm in the preliminary stages of implementing an AspectJ search facility
> > for ajdt. Following are some design ideas, thoughts and questions to the
> > user community - feedback is encouraged.
> > Search will be implemented as a new "AspectJ" page on the existing search
> > dialog. I would expect it to behave in a similar manner to the Java
> > Search page. There should be an entry field for text to search, which
> > will accept wildcard searches. There should be a "case-sensitive"
> > checkbox. There should be a set of things you can search for (see below),
> > and the ability to restrict the search in appropriate ways (see below).
> > You should also be able to restrict the scope of the search to workspace,
> > selected resources or working set.
> > I have included a link to a screen capture of a first pass at the search
> > dialog. Note that this is something I threw together quickly, and I
> > recongise that it's less than ideal. I include it here to better
> > illustrate the following discussion. Input on the GUI is welcome, as it
> > definitely needs more thought, but I think the design of how the search
> > works must come first.
> > Screen capture: http://members.rogers.com/30159374290/searchpage.html
> > Reminder: on the Java search page, you can search for
> > -type
> > -constructor
> > -method
> > -field
> > -package
> > and limit your search to:
> > -declarations (applies to all)
> > -references (applies to all)
> > -implementers (currently disabled, intended for interfaces)
> > -all occurrences (applies to all)
> > -read access (applies to fields)
> > -write access (applies to fields)
> > For the AspectJ search,
> > The search for/limit to paradigm used by the Java search doesn't seem to
> > hold up for AspectJ. In many cases (discussed below), you want to search
> > for constructs (like advice or pointcuts) that affect a particular
> > class/method/field (rather than searching for a subset of occurrences of a
> > particular class/method/field).
> > What should you be able to search for? Possibilities include:
> > (a) aspects
> > (b) pointcuts
> > (c) advice
> > (d) introductions
> > (e) warnings and errors
> > (f) softened exceptions
> > (g) other?
> * plus add the elements
> > -type
> > -constructor
> > -method
> > -field
> > -package
> from java. where type equals class and aspect!!! So you can drop then the
> search aspect option from the list, if the search type option is available.
> > Let's look at the issues with each of these in turn, in particular with
> > how it might be appropriate to limit the search in each case:
> > (a) aspects
> > -Certainly it makes sense to search for declarations of an aspect. Are
> > there any search limits that make sense here?
> see above
> > (b) pointcuts
> > -This was the trickiest one to get my mind around...
> > -You should have the ability to search for named pointcut declarations.
> > Are there any search limits that make sense here?
> > -What about all pointcuts that pick out join points in a particular type
> > or method? Here, you might specify that you're searching for a pointcut,
> > and then restrict the search to find only those pointcuts that pick out
> > join points in a named class/method/field. Does this make sense? Is it
> > useful? What about the primitive pointcuts used in advice - in that case,
> > there's no explicit pointcut definition to return from a search - rather,
> > we might find the advice that affects the named class/method/field (case
> > (c) below). Is a search for named pointcuts, plus case (c) all that's
> > useful, or is there something else lurking in here?
> I agree searching with pointcuts is the most trickiest element.
> And that is the point, where a developer needs as much support from the
> tools as possible. I will describe in short the optimal search-use cases
> for pointcuts, I have seen in my work, and by observing some other aspectJ
> developers.
> 1. I select a block of code, enter the search dialog, and get a list of
> all pointcuts (named/unnamed), who define joinpoints for this type of
> block of code.
> 2. I select a pointcut, enter the search dialog and get a list of all
> pointcuts , who have joinpoints (named/unnamed) with this pointcut in
> common.
> > (c) advice
> > -I wouldn't think you'd want to search for all "before" advice, or all
> > "after" advice etc. More likely you'd want to search for all advice that
> > affects a particular class/method/field. In that case, it may again make
> > more sense to search for advice and restrict the search to find only
> > advice affecting a named class or method (this is the example illustrated
> > by the screen capture).
> I agree with you that simple search for before advices, or all after
> advices is not very likely. Your use case is quite realistic.
> Based on my experience I see there a much more important use case, which
> is:
> Which advices of a conflicting type advices the same joinpoints. (whithout
> having a dominates subordinates relationship)
> this search can be narrowed, by specific types, by selecting a given
> advice.
> Also I want to search after advices, which directly or indirectly (through
> pointcut composition) use (or are affected, e.g. some pointcuts are
> excluded through &&!) by a given pointcut.
> > (d) introductions
> > -Again, this would seem to work like advice where you would want to search
> > for introductions, and restrict to those introductions affecting a named
> > class (method/field don't seem to apply here).
> > -Should a search for introductions find "declare parents" in the results
> > as well as member introductions? Would these be better separated into two
> > categories?
> it must find it!
> Also indirect introduction should be found. (e.g. container introduction)
> E.g. introducing a method to an interface, and introducing this interface
> to a class, aspect, etc.
> > (e) warnings and errors ("declare error", "declare warning")
> > -Would you want to search for these? One category or two? What kind of
> > restrictions might make sense?
> Quite likely, but not necessarily.
> > (f) softened exceptions ("declare soft")
> > -Would you want to search for these? What kind of restrictions might make
> > sense?
> Yes
> > (g) other
> > -Now that aspectJ will be built on the eclipse compiler, some things will
> > come to us for "free". A search for implementers on the Java Search page
> > (once enabled), would also return aspects in the result set. Would it be
> > useful to have an "implementers" search on the AspectJ search page that
> > returned only aspects that implement a specified interface?
> > -Is there anything I've missed that would be useful to search for?
> > Should the final GUI resemble anything similar to the included screenshot,
> > I would expect at a minimum that the "Named" and/or "Affecting + Named"
> > sections will be enabled/disabled as appropriate for each different type
> > of search. Examples: (1) if "Advice" is chosen in the "Search for"
> > section, the first "Named" will be disabled. (2) if Aspect is chosen,
> > "Named" would be disabled, and the "Affecting" + "Named" pair would be
> > enabled. (3) if "Pointcut is chosen, all would remain enabled.
> > Comments and feedback most welcome.
> > Regards,
> > Julie Waterhouse
> > AJDT Development Team
|
|
|
| Re: search function design [message #5304 is a reply to message #4964] |
Tue, 08 October 2002 09:05 |
Arno Schmidmeier
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi Julie,
hi all,
I tried you to explain my motivation for my comments.
I am aware, that several issues would be hard to implement
or even not possible with the limited resources you have.
However I felt they are important to note.
Comments between the lines of you message.
kind regards
Arno
P.S. I feel that these kind of discussion should be moved to the ajdt
mailing list. What is your opinon?
Julie Waterhouse wrote:
> First of all, Arno, I want to apologise for taking so long to reply to
> your post - things have been a little crazy recently! Second, I want to
> thank you for your thoughtful reply and suggestions.
> Some thoughts in response...
> You suggest adding the elements "type, constructor, method, field and
> package" to the AspectJ search page. This brings up the issue of how we
> separate functionality between the AspectJ search page and the Java search
> page in the search dialog. Since search for those items already exists on
> the Java search page, I would propose leaving them there. However, since
> we will soon be based on the Eclipse compiler, a search for a "type"
> should then also return aspects as well. So the Java page will have the
> ability to search for at least that AspectJ-related object. That means
> the line is a little blurred between the two pages. What do people think
> is the right solution? Do we repeat an aspect-only search on the AspectJ
> page? Or do we keep all type searching together in one place only on the
> Java page?
I would suggest searching everything in one place, just the java page.
Just because classes are nearly a total subset of aspects. (OK the
construction issue, but you can easily work around that) ...
My analogy:
In an C/C++ IDE you do not have different search windows for structs and
classes.
> Regarding your comments on searching for pointcuts, in your first use
> case, you suggest selecting a block of code and searching for pointcuts
> that pick out join points in that block (if I read it right). Mik, can
> you comment on the feasibility of selecting a block of code to search in
> this way? If that's not possible, is it easier to specify a particular
> type, method, or field and search for pointcuts that affect it? (should
> achieve almost the same function (not quite as specific), with a different
> UI).
This feature is very important for refactoring. With AspectJ you do today
refactoring in following way.
1. You select a line of code.
2. You look and try to find the pointcuts which may affect that block of
code.
and the advices of this code.
3. You refactor it.
4. You try to fix these pointcuts, so that the advices are applied in the
correct order again.
2. and 4. are manually error phrone tasks, even in small and medium sized
projects. if it gets to the large scale ist getting terrible. You start to
think twice if you want to refactor. ...
Tool/Search support would be of a great value.
My current ultimate dream would be a fully functional aspectJ aware
refactoring browser. But I keep on dreaming. ... ;-)
> Your second pointcut use case is interesting (searching for all pointcuts
> that share join points with a specified pointcut, again, if I'm reading
> you right). Mik, can you comment on the feasibility of implementing this
> one from an AspectJ perspective?
This is from my opinon the most critical search function, because it is
currently the most perfomed action in debugging large scale AspectJ
projects.
> I encourage others to contribute to this discussion as well. As the users
> of AspectJ in Eclipse, you know best what search functionality would be
> most useful to you, and you have an opportunity to influence the design.
> And I promise to be much quicker to respond next time!
> Regards,
> Julie Waterhouse
> AJDT Development Team
> Arno Schmidmeier wrote:
> > Hi Julie,
> > Hi all,
> > As Aspects can implement an interface and aspects can be subclasses from
> > standard java-classes. So aspects can play the role of standard java
> > objects.
> > And users will use aspects also in this way, as soon as the experience
> > with aspects increases.
> > So the dialog needs "all" the search functionality of plain java.
> > IMHO it is educational mistake to separate the search functionality in
> > plain java and in aspectJ specific elements. Both of these dialogs/panel
> > should be closely tied together.
> > IMHO the body of advices should be as small as possible, because advices
> > can currently not be adviced. But extracted methods from an advice can be
> > adviced.
> > So aspects of experienced aspectJ programmers have quite a buch of methods.
> > Aspects tend to look like standard classes, with some pointcuts and
> > advices in them.
> > A very important search functionality is searching after "conflicts",
> > "unkown" pointcuts, and advices affecting, influencing and intercepting
> > code. I am aware that these search case are not very often performed in
> > standard java.
> > Additionally I added some comments below:
> > Hope these comments help.
> > I appreciate any comments on mine, too!!!!
> > As they help me understand how other users work with IDEs in
> > aspectJ-programs!!!
> > regards
> > Arno Schmidmeier
> > Chief Scientist
> > Sirius Software Gmbh
> > Julie Waterhouse wrote:
> > > Hi all,
> > > I'm in the preliminary stages of implementing an AspectJ search facility
> > > for ajdt. Following are some design ideas, thoughts and questions to the
> > > user community - feedback is encouraged.
> > > Search will be implemented as a new "AspectJ" page on the existing search
> > > dialog. I would expect it to behave in a similar manner to the Java
> > > Search page. There should be an entry field for text to search, which
> > > will accept wildcard searches. There should be a "case-sensitive"
> > > checkbox. There should be a set of things you can search for (see
below),
> > > and the ability to restrict the search in appropriate ways (see below).
> > > You should also be able to restrict the scope of the search to workspace,
> > > selected resources or working set.
> > > I have included a link to a screen capture of a first pass at the search
> > > dialog. Note that this is something I threw together quickly, and I
> > > recongise that it's less than ideal. I include it here to better
> > > illustrate the following discussion. Input on the GUI is welcome, as it
> > > definitely needs more thought, but I think the design of how the search
> > > works must come first.
> > > Screen capture: http://members.rogers.com/30159374290/searchpage.html
> > > Reminder: on the Java search page, you can search for
> > > -type
> > > -constructor
> > > -method
> > > -field
> > > -package
> > > and limit your search to:
> > > -declarations (applies to all)
> > > -references (applies to all)
> > > -implementers (currently disabled, intended for interfaces)
> > > -all occurrences (applies to all)
> > > -read access (applies to fields)
> > > -write access (applies to fields)
> > > For the AspectJ search,
> > > The search for/limit to paradigm used by the Java search doesn't seem to
> > > hold up for AspectJ. In many cases (discussed below), you want to search
> > > for constructs (like advice or pointcuts) that affect a particular
> > > class/method/field (rather than searching for a subset of occurrences of
a
> > > particular class/method/field).
> > > What should you be able to search for? Possibilities include:
> > > (a) aspects
> > > (b) pointcuts
> > > (c) advice
> > > (d) introductions
> > > (e) warnings and errors
> > > (f) softened exceptions
> > > (g) other?
> > * plus add the elements
> > > -type
> > > -constructor
> > > -method
> > > -field
> > > -package
> > from java. where type equals class and aspect!!! So you can drop then the
> > search aspect option from the list, if the search type option is available.
> > > Let's look at the issues with each of these in turn, in particular with
> > > how it might be appropriate to limit the search in each case:
> > > (a) aspects
> > > -Certainly it makes sense to search for declarations of an aspect. Are
> > > there any search limits that make sense here?
> > see above
> > > (b) pointcuts
> > > -This was the trickiest one to get my mind around...
> > > -You should have the ability to search for named pointcut declarations.
> > > Are there any search limits that make sense here?
> > > -What about all pointcuts that pick out join points in a particular type
> > > or method? Here, you might specify that you're searching for a pointcut,
> > > and then restrict the search to find only those pointcuts that pick out
> > > join points in a named class/method/field. Does this make sense? Is it
> > > useful? What about the primitive pointcuts used in advice - in that
case,
> > > there's no explicit pointcut definition to return from a search - rather,
> > > we might find the advice that affects the named class/method/field (case
> > > (c) below). Is a search for named pointcuts, plus case (c) all that's
> > > useful, or is there something else lurking in here?
> > I agree searching with pointcuts is the most trickiest element.
> > And that is the point, where a developer needs as much support from the
> > tools as possible. I will describe in short the optimal search-use cases
> > for pointcuts, I have seen in my work, and by observing some other aspectJ
> > developers.
> > 1. I select a block of code, enter the search dialog, and get a list of
> > all pointcuts (named/unnamed), who define joinpoints for this type of
> > block of code.
> > 2. I select a pointcut, enter the search dialog and get a list of all
> > pointcuts , who have joinpoints (named/unnamed) with this pointcut in
> > common.
> > > (c) advice
> > > -I wouldn't think you'd want to search for all "before" advice, or all
> > > "after" advice etc. More likely you'd want to search for all advice that
> > > affects a particular class/method/field. In that case, it may again make
> > > more sense to search for advice and restrict the search to find only
> > > advice affecting a named class or method (this is the example illustrated
> > > by the screen capture).
> > I agree with you that simple search for before advices, or all after
> > advices is not very likely. Your use case is quite realistic.
> > Based on my experience I see there a much more important use case, which
> > is:
> > Which advices of a conflicting type advices the same joinpoints. (whithout
> > having a dominates subordinates relationship)
> > this search can be narrowed, by specific types, by selecting a given
> > advice.
> > Also I want to search after advices, which directly or indirectly (through
> > pointcut composition) use (or are affected, e.g. some pointcuts are
> > excluded through &&!) by a given pointcut.
> > > (d) introductions
> > > -Again, this would seem to work like advice where you would want to
search
> > > for introductions, and restrict to those introductions affecting a named
> > > class (method/field don't seem to apply here).
> > > -Should a search for introductions find "declare parents" in the results
> > > as well as member introductions? Would these be better separated into
two
> > > categories?
> > it must find it!
> > Also indirect introduction should be found. (e.g. container introduction)
> > E.g. introducing a method to an interface, and introducing this interface
> > to a class, aspect, etc.
> > > (e) warnings and errors ("declare error", "declare warning")
> > > -Would you want to search for these? One category or two? What kind of
> > > restrictions might make sense?
> > Quite likely, but not necessarily.
> > > (f) softened exceptions ("declare soft")
> > > -Would you want to search for these? What kind of restrictions might
make
> > > sense?
> > Yes
> > > (g) other
> > > -Now that aspectJ will be built on the eclipse compiler, some things will
> > > come to us for "free". A search for implementers on the Java Search page
> > > (once enabled), would also return aspects in the result set. Would it be
> > > useful to have an "implementers" search on the AspectJ search page that
> > > returned only aspects that implement a specified interface?
> > > -Is there anything I've missed that would be useful to search for?
> > > Should the final GUI resemble anything similar to the included
screenshot,
> > > I would expect at a minimum that the "Named" and/or "Affecting + Named"
> > > sections will be enabled/disabled as appropriate for each different type
> > > of search. Examples: (1) if "Advice" is chosen in the "Search for"
> > > section, the first "Named" will be disabled. (2) if Aspect is chosen,
> > > "Named" would be disabled, and the "Affecting" + "Named" pair would be
> > > enabled. (3) if "Pointcut is chosen, all would remain enabled.
> > > Comments and feedback most welcome.
> > > Regards,
> > > Julie Waterhouse
> > > AJDT Development Team
|
|
|
| Re: search function design [message #6931 is a reply to message #5304] |
Thu, 10 October 2002 20:06 |
| Eclipse User |
|
|
|
Originally posted by: Mik.Kersten.parc.com
"Arno Schmidmeier" <Arno.Schmidmeier@sirius-eos.com> wrote in message
news:anu751$rih$1@rogue.oti.com...
.. . .
> > You suggest adding the elements "type, constructor, method, field and
> > package" to the AspectJ search page. This brings up the issue of how we
> > separate functionality between the AspectJ search page and the Java
search
> > page in the search dialog. Since search for those items already exists
on
> > the Java search page, I would propose leaving them there. However,
since
> > we will soon be based on the Eclipse compiler, a search for a "type"
> > should then also return aspects as well. So the Java page will have the
> > ability to search for at least that AspectJ-related object. That means
> > the line is a little blurred between the two pages. What do people
think
> > is the right solution? Do we repeat an aspect-only search on the
AspectJ
> > page? Or do we keep all type searching together in one place only on
the
> > Java page?
>
> I would suggest searching everything in one place, just the java page.
> Just because classes are nearly a total subset of aspects. (OK the
> construction issue, but you can easily work around that) ...
> My analogy:
> In an C/C++ IDE you do not have different search windows for structs and
> classes.
I agree with Arno that splitting up the AspectJ and Java parts in is
problematic since an AspectJ programmer should not need to make a conceptual
split between the two when searching. I suggest that we duplicate the Java
Search page and extend it to include AspectJ declarations. Then we can take
the more interesting search facilities that you're talking about and create
a "Crosscutting Search" page.
Borrowing from Julie's earlier message, the "AspectJ Search" would extend
the "Search For" to include the named :
- named pointcut
- inter-type declaration
- aspect (if we decide to break Type into Class and Interface)
There are some unnamed AspectJ members that could also be useful to search
if a limited scope is used (e.g. find all delcare parents in this package):
- advice
- pointcut
- declare warning/error
- declare parents
- delcare soft
In addition to the current 6 options "Limit To" should probably contain:
- before (for advice)
- after (for advice)
- around (for advice)
- message (for declare warning/error)
That last one is important for finding which declare is causing a particular
task list error or warning to show.
Everything in the "AspectJ Search" page can be searched from the sources and
does not require a compile. This isn't true for the pointcut related
searches that you're describing. Those searches are considerably different
from what users expect in a Java search, and will require a different UI.
So I think they deserve their own "Crosscutting Search" page. I also think
that we've filled up the UI real-estate on the "AspectJ Search" page.
> > Regarding your comments on searching for pointcuts, in your first use
> > case, you suggest selecting a block of code and searching for pointcuts
> > that pick out join points in that block (if I read it right). Mik, can
> > you comment on the feasibility of selecting a block of code to search in
> > this way? If that's not possible, is it easier to specify a particular
> > type, method, or field and search for pointcuts that affect it? (should
> > achieve almost the same function (not quite as specific), with a
different
> > UI).
>
> This feature is very important for refactoring. With AspectJ you do today
> refactoring in following way.
>
> 1. You select a line of code.
> 2. You look and try to find the pointcuts which may affect that block of
> code.
> and the advices of this code.
> 3. You refactor it.
> 4. You try to fix these pointcuts, so that the advices are applied in the
> correct order again.
> 2. and 4. are manually error phrone tasks, even in small and medium sized
> projects. if it gets to the large scale ist getting terrible. You start to
> think twice if you want to refactor. ...
> Tool/Search support would be of a great value.
>
> My current ultimate dream would be a fully functional aspectJ aware
> refactoring browser. But I keep on dreaming. ... ;-)
>
> > Your second pointcut use case is interesting (searching for all
pointcuts
> > that share join points with a specified pointcut, again, if I'm reading
> > you right). Mik, can you comment on the feasibility of implementing
this
> > one from an AspectJ perspective?
>
> This is from my opinon the most critical search function, because it is
> currently the most perfomed action in debugging large scale AspectJ
> projects.
I also think that the search facilities should cover what's required by
AspectJ-related refactorings. JDT's search does a good job of that for
Java. The goal is to eventually support AspectJ-aware refactorings and AO
refactorings in AJDT. But those will use similar pointcut-based searches to
the ones described above, and it would be good to expose them to the user
before we make AspectJ-specific refactorings work.
We should focus on getting the core "AspectJ Search" right first, but keep
in mind use cases like Arno's for defining the "Crosscutting Structure"
searches that we want to expose.
Mik
--
Mik Kersten
Development Tools Lead
AspectJ Team, Palo Alto Research Center
http://www.parc.com/mkersten
|
|
|
| Re: search function design [message #7169 is a reply to message #6931] |
Thu, 24 October 2002 14:10 |
Julie Waterhouse
Messages: 42
Registered: July 2009 |
Member |
|
|
I agree with Mik's suggestion of splitting search into 2 pages -- a search
page with the standard Java plus basic AspectJ extensions that can be
searched based solely on the source, and a "cross-cutting search page."
I've started with the simpler of the two, the source-based, and have
included a link to a new mockup here for discussion:
http://members.rogers.com/30159374290/searchpage2.html
Some questions/issues that came up:
"Search string" entry field:
============================
When should the search string entry field be enabled? In the original
Java search, it was always enabled, but in AspectJ, we have things to
search for that are not named.
1. For Advice, Declare Warning/Error and Declare Soft, I propose disabling
the search string entry field.
2. For inter-type declaration, I propose leaving it enabled, and allowing
the user to enter the field or method name for the introduced member. Of
course, below I was going to note that I had lumped "Declare parents"
under this category too (mostly to try and save on real estate...), but
there might be a good reason to split it out. Declare parents should
probably have the search string disabled, and just find all declarations
within the given scope. Opinions?
3. Pointcut is the tricky one (always!) because it can be named or not.
For that, we may need to do a check - leave the entry field enabled, and
if there is something in it, search for pointcuts named that, or if it's
empty, search for all pointcuts in the specified scope. Other suggestions?
What are appropriate "Limit to" restrictions for the new "Search for"
items?
============================================================ ================
1. Inter-type declaration:
We could have "Declarations" where it would find the place in the aspect
where it's defined, and "References" where it would find the class
affected. But that's moving beyond the source stuff Mik talked about
restricting this page to, and into the "cross-cutting" type of search.
So, I propose just enabling "Declarations" and having the search find all
inter-type declarations within the named scope. (Would anyone prefer
enabling only "All occurrences?")
2. Advice:
I propose enabling only "Declarations" (would catch all types - before,
after and around), "Before," "After" and "Around."
3. Declare warning/error:
I propose enabling only "Declarations" and "Message."
4. Declare soft:
I propose enabling only "Declarations."
5. Pointcut:
I propose enabling only "Declarations."
Scope:
======
Should we prevent the user from searching for all
-unnamed pointcut
-declare parents
-advice
-declare warning/error
-declare soft
in the workspace (just because the search could be so huge)? It could be
implemented such that if you select "workspace", those search options are
disabled. Only if you have something selected (e.g., a type, package or
project) before you open search will you see the option when the dialog
opens. If you switch the scope to "workspace", they'll be disabled (and
the current selection set back to "Type"). Conversely, if you go into the
dialog, with nothing selected and change the scope to "working set", the
options will become enabled.
The alternative is to allow the user to search all advice (or declare
parents, or ...) in the entire workspace.
Notes:
======
I have not separated out "Declare parents" as a separate "Search for"
item, and have assumed that those will be captured by the "inter-type
declaration" search. See above for some discussion why this might not be
a good idea -- but my dialog is getting big! If you think it should be a
separate item, then we *really* need to address real estate issues. Even
now, the dialog for the AspectJ search is longer than all the others, so
the dialog is now about 100 pixels longer that it used to be.
You may notice a bit of a hack. When the search string entry field is
disabled, you'll see a "*" in it. This is to force the Search button on
the dialog to be enabled - it's only enabled when there's something in
that entry field.
Note that there are problems with the keyboard mnemonics on this page.
"After" and "Search for" both use 'a'. "Pointcut" and "Case-sensitive"
both use 't' (this was a problem on the original Java Search dialog, where
"Type" and "Case-sensitive" both used 't'). I may be able to make them
unique, but not without changing them from the original Java page -- as I
already did with Type (which is less than desirable). I gave up on this
one 'cause it was driving me nuts ;-). 'j', 'q', and 'x' are the only
alphabetic characters not used!
Okay, that's enough for now... This is getting long!
Julie Waterhouse
AJDT Development Team
|
|
|
| Re: search function design [message #561543 is a reply to message #4267] |
Thu, 19 September 2002 09:03 |
Arno Schmidmeier
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi Julie,
Hi all,
As Aspects can implement an interface and aspects can be subclasses from
standard java-classes. So aspects can play the role of standard java
objects.
And users will use aspects also in this way, as soon as the experience
with aspects increases.
So the dialog needs "all" the search functionality of plain java.
IMHO it is educational mistake to separate the search functionality in
plain java and in aspectJ specific elements. Both of these dialogs/panel
should be closely tied together.
IMHO the body of advices should be as small as possible, because advices
can currently not be adviced. But extracted methods from an advice can be
adviced.
So aspects of experienced aspectJ programmers have quite a buch of methods.
Aspects tend to look like standard classes, with some pointcuts and
advices in them.
A very important search functionality is searching after "conflicts",
"unkown" pointcuts, and advices affecting, influencing and intercepting
code. I am aware that these search case are not very often performed in
standard java.
Additionally I added some comments below:
Hope these comments help.
I appreciate any comments on mine, too!!!!
As they help me understand how other users work with IDEs in
aspectJ-programs!!!
regards
Arno Schmidmeier
Chief Scientist
Sirius Software Gmbh
Julie Waterhouse wrote:
> Hi all,
> I'm in the preliminary stages of implementing an AspectJ search facility
> for ajdt. Following are some design ideas, thoughts and questions to the
> user community - feedback is encouraged.
> Search will be implemented as a new "AspectJ" page on the existing search
> dialog. I would expect it to behave in a similar manner to the Java
> Search page. There should be an entry field for text to search, which
> will accept wildcard searches. There should be a "case-sensitive"
> checkbox. There should be a set of things you can search for (see below),
> and the ability to restrict the search in appropriate ways (see below).
> You should also be able to restrict the scope of the search to workspace,
> selected resources or working set.
> I have included a link to a screen capture of a first pass at the search
> dialog. Note that this is something I threw together quickly, and I
> recongise that it's less than ideal. I include it here to better
> illustrate the following discussion. Input on the GUI is welcome, as it
> definitely needs more thought, but I think the design of how the search
> works must come first.
> Screen capture: http://members.rogers.com/30159374290/searchpage.html
> Reminder: on the Java search page, you can search for
> -type
> -constructor
> -method
> -field
> -package
> and limit your search to:
> -declarations (applies to all)
> -references (applies to all)
> -implementers (currently disabled, intended for interfaces)
> -all occurrences (applies to all)
> -read access (applies to fields)
> -write access (applies to fields)
> For the AspectJ search,
> The search for/limit to paradigm used by the Java search doesn't seem to
> hold up for AspectJ. In many cases (discussed below), you want to search
> for constructs (like advice or pointcuts) that affect a particular
> class/method/field (rather than searching for a subset of occurrences of a
> particular class/method/field).
> What should you be able to search for? Possibilities include:
> (a) aspects
> (b) pointcuts
> (c) advice
> (d) introductions
> (e) warnings and errors
> (f) softened exceptions
> (g) other?
* plus add the elements
> -type
> -constructor
> -method
> -field
> -package
from java. where type equals class and aspect!!! So you can drop then the
search aspect option from the list, if the search type option is available.
> Let's look at the issues with each of these in turn, in particular with
> how it might be appropriate to limit the search in each case:
> (a) aspects
> -Certainly it makes sense to search for declarations of an aspect. Are
> there any search limits that make sense here?
see above
> (b) pointcuts
> -This was the trickiest one to get my mind around...
> -You should have the ability to search for named pointcut declarations.
> Are there any search limits that make sense here?
> -What about all pointcuts that pick out join points in a particular type
> or method? Here, you might specify that you're searching for a pointcut,
> and then restrict the search to find only those pointcuts that pick out
> join points in a named class/method/field. Does this make sense? Is it
> useful? What about the primitive pointcuts used in advice - in that case,
> there's no explicit pointcut definition to return from a search - rather,
> we might find the advice that affects the named class/method/field (case
> (c) below). Is a search for named pointcuts, plus case (c) all that's
> useful, or is there something else lurking in here?
I agree searching with pointcuts is the most trickiest element.
And that is the point, where a developer needs as much support from the
tools as possible. I will describe in short the optimal search-use cases
for pointcuts, I have seen in my work, and by observing some other aspectJ
developers.
1. I select a block of code, enter the search dialog, and get a list of
all pointcuts (named/unnamed), who define joinpoints for this type of
block of code.
2. I select a pointcut, enter the search dialog and get a list of all
pointcuts , who have joinpoints (named/unnamed) with this pointcut in
common.
> (c) advice
> -I wouldn't think you'd want to search for all "before" advice, or all
> "after" advice etc. More likely you'd want to search for all advice that
> affects a particular class/method/field. In that case, it may again make
> more sense to search for advice and restrict the search to find only
> advice affecting a named class or method (this is the example illustrated
> by the screen capture).
I agree with you that simple search for before advices, or all after
advices is not very likely. Your use case is quite realistic.
Based on my experience I see there a much more important use case, which
is:
Which advices of a conflicting type advices the same joinpoints. (whithout
having a dominates subordinates relationship)
this search can be narrowed, by specific types, by selecting a given
advice.
Also I want to search after advices, which directly or indirectly (through
pointcut composition) use (or are affected, e.g. some pointcuts are
excluded through &&!) by a given pointcut.
> (d) introductions
> -Again, this would seem to work like advice where you would want to search
> for introductions, and restrict to those introductions affecting a named
> class (method/field don't seem to apply here).
> -Should a search for introductions find "declare parents" in the results
> as well as member introductions? Would these be better separated into two
> categories?
it must find it!
Also indirect introduction should be found. (e.g. container introduction)
E.g. introducing a method to an interface, and introducing this interface
to a class, aspect, etc.
> (e) warnings and errors ("declare error", "declare warning")
> -Would you want to search for these? One category or two? What kind of
> restrictions might make sense?
Quite likely, but not necessarily.
> (f) softened exceptions ("declare soft")
> -Would you want to search for these? What kind of restrictions might make
> sense?
Yes
> (g) other
> -Now that aspectJ will be built on the eclipse compiler, some things will
> come to us for "free". A search for implementers on the Java Search page
> (once enabled), would also return aspects in the result set. Would it be
> useful to have an "implementers" search on the AspectJ search page that
> returned only aspects that implement a specified interface?
> -Is there anything I've missed that would be useful to search for?
> Should the final GUI resemble anything similar to the included screenshot,
> I would expect at a minimum that the "Named" and/or "Affecting + Named"
> sections will be enabled/disabled as appropriate for each different type
> of search. Examples: (1) if "Advice" is chosen in the "Search for"
> section, the first "Named" will be disabled. (2) if Aspect is chosen,
> "Named" would be disabled, and the "Affecting" + "Named" pair would be
> enabled. (3) if "Pointcut is chosen, all would remain enabled.
> Comments and feedback most welcome.
> Regards,
> Julie Waterhouse
> AJDT Development Team
|
|
|
| Re: search function design [message #561737 is a reply to message #4341] |
Thu, 03 October 2002 14:47 |
Julie Waterhouse
Messages: 42
Registered: July 2009 |
Member |
|
|
First of all, Arno, I want to apologise for taking so long to reply to
your post - things have been a little crazy recently! Second, I want to
thank you for your thoughtful reply and suggestions.
Some thoughts in response...
You suggest adding the elements "type, constructor, method, field and
package" to the AspectJ search page. This brings up the issue of how we
separate functionality between the AspectJ search page and the Java search
page in the search dialog. Since search for those items already exists on
the Java search page, I would propose leaving them there. However, since
we will soon be based on the Eclipse compiler, a search for a "type"
should then also return aspects as well. So the Java page will have the
ability to search for at least that AspectJ-related object. That means
the line is a little blurred between the two pages. What do people think
is the right solution? Do we repeat an aspect-only search on the AspectJ
page? Or do we keep all type searching together in one place only on the
Java page?
Regarding your comments on searching for pointcuts, in your first use
case, you suggest selecting a block of code and searching for pointcuts
that pick out join points in that block (if I read it right). Mik, can
you comment on the feasibility of selecting a block of code to search in
this way? If that's not possible, is it easier to specify a particular
type, method, or field and search for pointcuts that affect it? (should
achieve almost the same function (not quite as specific), with a different
UI).
Your second pointcut use case is interesting (searching for all pointcuts
that share join points with a specified pointcut, again, if I'm reading
you right). Mik, can you comment on the feasibility of implementing this
one from an AspectJ perspective?
I encourage others to contribute to this discussion as well. As the users
of AspectJ in Eclipse, you know best what search functionality would be
most useful to you, and you have an opportunity to influence the design.
And I promise to be much quicker to respond next time!
Regards,
Julie Waterhouse
AJDT Development Team
Arno Schmidmeier wrote:
> Hi Julie,
> Hi all,
> As Aspects can implement an interface and aspects can be subclasses from
> standard java-classes. So aspects can play the role of standard java
> objects.
> And users will use aspects also in this way, as soon as the experience
> with aspects increases.
> So the dialog needs "all" the search functionality of plain java.
> IMHO it is educational mistake to separate the search functionality in
> plain java and in aspectJ specific elements. Both of these dialogs/panel
> should be closely tied together.
> IMHO the body of advices should be as small as possible, because advices
> can currently not be adviced. But extracted methods from an advice can be
> adviced.
> So aspects of experienced aspectJ programmers have quite a buch of methods.
> Aspects tend to look like standard classes, with some pointcuts and
> advices in them.
> A very important search functionality is searching after "conflicts",
> "unkown" pointcuts, and advices affecting, influencing and intercepting
> code. I am aware that these search case are not very often performed in
> standard java.
> Additionally I added some comments below:
> Hope these comments help.
> I appreciate any comments on mine, too!!!!
> As they help me understand how other users work with IDEs in
> aspectJ-programs!!!
> regards
> Arno Schmidmeier
> Chief Scientist
> Sirius Software Gmbh
> Julie Waterhouse wrote:
> > Hi all,
> > I'm in the preliminary stages of implementing an AspectJ search facility
> > for ajdt. Following are some design ideas, thoughts and questions to the
> > user community - feedback is encouraged.
> > Search will be implemented as a new "AspectJ" page on the existing search
> > dialog. I would expect it to behave in a similar manner to the Java
> > Search page. There should be an entry field for text to search, which
> > will accept wildcard searches. There should be a "case-sensitive"
> > checkbox. There should be a set of things you can search for (see below),
> > and the ability to restrict the search in appropriate ways (see below).
> > You should also be able to restrict the scope of the search to workspace,
> > selected resources or working set.
> > I have included a link to a screen capture of a first pass at the search
> > dialog. Note that this is something I threw together quickly, and I
> > recongise that it's less than ideal. I include it here to better
> > illustrate the following discussion. Input on the GUI is welcome, as it
> > definitely needs more thought, but I think the design of how the search
> > works must come first.
> > Screen capture: http://members.rogers.com/30159374290/searchpage.html
> > Reminder: on the Java search page, you can search for
> > -type
> > -constructor
> > -method
> > -field
> > -package
> > and limit your search to:
> > -declarations (applies to all)
> > -references (applies to all)
> > -implementers (currently disabled, intended for interfaces)
> > -all occurrences (applies to all)
> > -read access (applies to fields)
> > -write access (applies to fields)
> > For the AspectJ search,
> > The search for/limit to paradigm used by the Java search doesn't seem to
> > hold up for AspectJ. In many cases (discussed below), you want to search
> > for constructs (like advice or pointcuts) that affect a particular
> > class/method/field (rather than searching for a subset of occurrences of a
> > particular class/method/field).
> > What should you be able to search for? Possibilities include:
> > (a) aspects
> > (b) pointcuts
> > (c) advice
> > (d) introductions
> > (e) warnings and errors
> > (f) softened exceptions
> > (g) other?
> * plus add the elements
> > -type
> > -constructor
> > -method
> > -field
> > -package
> from java. where type equals class and aspect!!! So you can drop then the
> search aspect option from the list, if the search type option is available.
> > Let's look at the issues with each of these in turn, in particular with
> > how it might be appropriate to limit the search in each case:
> > (a) aspects
> > -Certainly it makes sense to search for declarations of an aspect. Are
> > there any search limits that make sense here?
> see above
> > (b) pointcuts
> > -This was the trickiest one to get my mind around...
> > -You should have the ability to search for named pointcut declarations.
> > Are there any search limits that make sense here?
> > -What about all pointcuts that pick out join points in a particular type
> > or method? Here, you might specify that you're searching for a pointcut,
> > and then restrict the search to find only those pointcuts that pick out
> > join points in a named class/method/field. Does this make sense? Is it
> > useful? What about the primitive pointcuts used in advice - in that case,
> > there's no explicit pointcut definition to return from a search - rather,
> > we might find the advice that affects the named class/method/field (case
> > (c) below). Is a search for named pointcuts, plus case (c) all that's
> > useful, or is there something else lurking in here?
> I agree searching with pointcuts is the most trickiest element.
> And that is the point, where a developer needs as much support from the
> tools as possible. I will describe in short the optimal search-use cases
> for pointcuts, I have seen in my work, and by observing some other aspectJ
> developers.
> 1. I select a block of code, enter the search dialog, and get a list of
> all pointcuts (named/unnamed), who define joinpoints for this type of
> block of code.
> 2. I select a pointcut, enter the search dialog and get a list of all
> pointcuts , who have joinpoints (named/unnamed) with this pointcut in
> common.
> > (c) advice
> > -I wouldn't think you'd want to search for all "before" advice, or all
> > "after" advice etc. More likely you'd want to search for all advice that
> > affects a particular class/method/field. In that case, it may again make
> > more sense to search for advice and restrict the search to find only
> > advice affecting a named class or method (this is the example illustrated
> > by the screen capture).
> I agree with you that simple search for before advices, or all after
> advices is not very likely. Your use case is quite realistic.
> Based on my experience I see there a much more important use case, which
> is:
> Which advices of a conflicting type advices the same joinpoints. (whithout
> having a dominates subordinates relationship)
> this search can be narrowed, by specific types, by selecting a given
> advice.
> Also I want to search after advices, which directly or indirectly (through
> pointcut composition) use (or are affected, e.g. some pointcuts are
> excluded through &&!) by a given pointcut.
> > (d) introductions
> > -Again, this would seem to work like advice where you would want to search
> > for introductions, and restrict to those introductions affecting a named
> > class (method/field don't seem to apply here).
> > -Should a search for introductions find "declare parents" in the results
> > as well as member introductions? Would these be better separated into two
> > categories?
> it must find it!
> Also indirect introduction should be found. (e.g. container introduction)
> E.g. introducing a method to an interface, and introducing this interface
> to a class, aspect, etc.
> > (e) warnings and errors ("declare error", "declare warning")
> > -Would you want to search for these? One category or two? What kind of
> > restrictions might make sense?
> Quite likely, but not necessarily.
> > (f) softened exceptions ("declare soft")
> > -Would you want to search for these? What kind of restrictions might make
> > sense?
> Yes
> > (g) other
> > -Now that aspectJ will be built on the eclipse compiler, some things will
> > come to us for "free". A search for implementers on the Java Search page
> > (once enabled), would also return aspects in the result set. Would it be
> > useful to have an "implementers" search on the AspectJ search page that
> > returned only aspects that implement a specified interface?
> > -Is there anything I've missed that would be useful to search for?
> > Should the final GUI resemble anything similar to the included screenshot,
> > I would expect at a minimum that the "Named" and/or "Affecting + Named"
> > sections will be enabled/disabled as appropriate for each different type
> > of search. Examples: (1) if "Advice" is chosen in the "Search for"
> > section, the first "Named" will be disabled. (2) if Aspect is chosen,
> > "Named" would be disabled, and the "Affecting" + "Named" pair would be
> > enabled. (3) if "Pointcut is chosen, all would remain enabled.
> > Comments and feedback most welcome.
> > Regards,
> > Julie Waterhouse
> > AJDT Development Team
|
|
|
| Re: search function design [message #561839 is a reply to message #4964] |
Tue, 08 October 2002 09:05 |
Arno Schmidmeier
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi Julie,
hi all,
I tried you to explain my motivation for my comments.
I am aware, that several issues would be hard to implement
or even not possible with the limited resources you have.
However I felt they are important to note.
Comments between the lines of you message.
kind regards
Arno
P.S. I feel that these kind of discussion should be moved to the ajdt
mailing list. What is your opinon?
Julie Waterhouse wrote:
> First of all, Arno, I want to apologise for taking so long to reply to
> your post - things have been a little crazy recently! Second, I want to
> thank you for your thoughtful reply and suggestions.
> Some thoughts in response...
> You suggest adding the elements "type, constructor, method, field and
> package" to the AspectJ search page. This brings up the issue of how we
> separate functionality between the AspectJ search page and the Java search
> page in the search dialog. Since search for those items already exists on
> the Java search page, I would propose leaving them there. However, since
> we will soon be based on the Eclipse compiler, a search for a "type"
> should then also return aspects as well. So the Java page will have the
> ability to search for at least that AspectJ-related object. That means
> the line is a little blurred between the two pages. What do people think
> is the right solution? Do we repeat an aspect-only search on the AspectJ
> page? Or do we keep all type searching together in one place only on the
> Java page?
I would suggest searching everything in one place, just the java page.
Just because classes are nearly a total subset of aspects. (OK the
construction issue, but you can easily work around that) ...
My analogy:
In an C/C++ IDE you do not have different search windows for structs and
classes.
> Regarding your comments on searching for pointcuts, in your first use
> case, you suggest selecting a block of code and searching for pointcuts
> that pick out join points in that block (if I read it right). Mik, can
> you comment on the feasibility of selecting a block of code to search in
> this way? If that's not possible, is it easier to specify a particular
> type, method, or field and search for pointcuts that affect it? (should
> achieve almost the same function (not quite as specific), with a different
> UI).
This feature is very important for refactoring. With AspectJ you do today
refactoring in following way.
1. You select a line of code.
2. You look and try to find the pointcuts which may affect that block of
code.
and the advices of this code.
3. You refactor it.
4. You try to fix these pointcuts, so that the advices are applied in the
correct order again.
2. and 4. are manually error phrone tasks, even in small and medium sized
projects. if it gets to the large scale ist getting terrible. You start to
think twice if you want to refactor. ...
Tool/Search support would be of a great value.
My current ultimate dream would be a fully functional aspectJ aware
refactoring browser. But I keep on dreaming. ... ;-)
> Your second pointcut use case is interesting (searching for all pointcuts
> that share join points with a specified pointcut, again, if I'm reading
> you right). Mik, can you comment on the feasibility of implementing this
> one from an AspectJ perspective?
This is from my opinon the most critical search function, because it is
currently the most perfomed action in debugging large scale AspectJ
projects.
> I encourage others to contribute to this discussion as well. As the users
> of AspectJ in Eclipse, you know best what search functionality would be
> most useful to you, and you have an opportunity to influence the design.
> And I promise to be much quicker to respond next time!
> Regards,
> Julie Waterhouse
> AJDT Development Team
> Arno Schmidmeier wrote:
> > Hi Julie,
> > Hi all,
> > As Aspects can implement an interface and aspects can be subclasses from
> > standard java-classes. So aspects can play the role of standard java
> > objects.
> > And users will use aspects also in this way, as soon as the experience
> > with aspects increases.
> > So the dialog needs "all" the search functionality of plain java.
> > IMHO it is educational mistake to separate the search functionality in
> > plain java and in aspectJ specific elements. Both of these dialogs/panel
> > should be closely tied together.
> > IMHO the body of advices should be as small as possible, because advices
> > can currently not be adviced. But extracted methods from an advice can be
> > adviced.
> > So aspects of experienced aspectJ programmers have quite a buch of methods.
> > Aspects tend to look like standard classes, with some pointcuts and
> > advices in them.
> > A very important search functionality is searching after "conflicts",
> > "unkown" pointcuts, and advices affecting, influencing and intercepting
> > code. I am aware that these search case are not very often performed in
> > standard java.
> > Additionally I added some comments below:
> > Hope these comments help.
> > I appreciate any comments on mine, too!!!!
> > As they help me understand how other users work with IDEs in
> > aspectJ-programs!!!
> > regards
> > Arno Schmidmeier
> > Chief Scientist
> > Sirius Software Gmbh
> > Julie Waterhouse wrote:
> > > Hi all,
> > > I'm in the preliminary stages of implementing an AspectJ search facility
> > > for ajdt. Following are some design ideas, thoughts and questions to the
> > > user community - feedback is encouraged.
> > > Search will be implemented as a new "AspectJ" page on the existing search
> > > dialog. I would expect it to behave in a similar manner to the Java
> > > Search page. There should be an entry field for text to search, which
> > > will accept wildcard searches. There should be a "case-sensitive"
> > > checkbox. There should be a set of things you can search for (see
below),
> > > and the ability to restrict the search in appropriate ways (see below).
> > > You should also be able to restrict the scope of the search to workspace,
> > > selected resources or working set.
> > > I have included a link to a screen capture of a first pass at the search
> > > dialog. Note that this is something I threw together quickly, and I
> > > recongise that it's less than ideal. I include it here to better
> > > illustrate the following discussion. Input on the GUI is welcome, as it
> > > definitely needs more thought, but I think the design of how the search
> > > works must come first.
> > > Screen capture: http://members.rogers.com/30159374290/searchpage.html
> > > Reminder: on the Java search page, you can search for
> > > -type
> > > -constructor
> > > -method
> > > -field
> > > -package
> > > and limit your search to:
> > > -declarations (applies to all)
> > > -references (applies to all)
> > > -implementers (currently disabled, intended for interfaces)
> > > -all occurrences (applies to all)
> > > -read access (applies to fields)
> > > -write access (applies to fields)
> > > For the AspectJ search,
> > > The search for/limit to paradigm used by the Java search doesn't seem to
> > > hold up for AspectJ. In many cases (discussed below), you want to search
> > > for constructs (like advice or pointcuts) that affect a particular
> > > class/method/field (rather than searching for a subset of occurrences of
a
> > > particular class/method/field).
> > > What should you be able to search for? Possibilities include:
> > > (a) aspects
> > > (b) pointcuts
> > > (c) advice
> > > (d) introductions
> > > (e) warnings and errors
> > > (f) softened exceptions
> > > (g) other?
> > * plus add the elements
> > > -type
> > > -constructor
> > > -method
> > > -field
> > > -package
> > from java. where type equals class and aspect!!! So you can drop then the
> > search aspect option from the list, if the search type option is available.
> > > Let's look at the issues with each of these in turn, in particular with
> > > how it might be appropriate to limit the search in each case:
> > > (a) aspects
> > > -Certainly it makes sense to search for declarations of an aspect. Are
> > > there any search limits that make sense here?
> > see above
> > > (b) pointcuts
> > > -This was the trickiest one to get my mind around...
> > > -You should have the ability to search for named pointcut declarations.
> > > Are there any search limits that make sense here?
> > > -What about all pointcuts that pick out join points in a particular type
> > > or method? Here, you might specify that you're searching for a pointcut,
> > > and then restrict the search to find only those pointcuts that pick out
> > > join points in a named class/method/field. Does this make sense? Is it
> > > useful? What about the primitive pointcuts used in advice - in that
case,
> > > there's no explicit pointcut definition to return from a search - rather,
> > > we might find the advice that affects the named class/method/field (case
> > > (c) below). Is a search for named pointcuts, plus case (c) all that's
> > > useful, or is there something else lurking in here?
> > I agree searching with pointcuts is the most trickiest element.
> > And that is the point, where a developer needs as much support from the
> > tools as possible. I will describe in short the optimal search-use cases
> > for pointcuts, I have seen in my work, and by observing some other aspectJ
> > developers.
> > 1. I select a block of code, enter the search dialog, and get a list of
> > all pointcuts (named/unnamed), who define joinpoints for this type of
> > block of code.
> > 2. I select a pointcut, enter the search dialog and get a list of all
> > pointcuts , who have joinpoints (named/unnamed) with this pointcut in
> > common.
> > > (c) advice
> > > -I wouldn't think you'd want to search for all "before" advice, or all
> > > "after" advice etc. More likely you'd want to search for all advice that
> > > affects a particular class/method/field. In that case, it may again make
> > > more sense to search for advice and restrict the search to find only
> > > advice affecting a named class or method (this is the example illustrated
> > > by the screen capture).
> > I agree with you that simple search for before advices, or all after
> > advices is not very likely. Your use case is quite realistic.
> > Based on my experience I see there a much more important use case, which
> > is:
> > Which advices of a conflicting type advices the same joinpoints. (whithout
> > having a dominates subordinates relationship)
> > this search can be narrowed, by specific types, by selecting a given
> > advice.
> > Also I want to search after advices, which directly or indirectly (through
> > pointcut composition) use (or are affected, e.g. some pointcuts are
> > excluded through &&!) by a given pointcut.
> > > (d) introductions
> > > -Again, this would seem to work like advice where you would want to
search
> > > for introductions, and restrict to those introductions affecting a named
> > > class (method/field don't seem to apply here).
> > > -Should a search for introductions find "declare parents" in the results
> > > as well as member introductions? Would these be better separated into
two
> > > categories?
> > it must find it!
> > Also indirect introduction should be found. (e.g. container introduction)
> > E.g. introducing a method to an interface, and introducing this interface
> > to a class, aspect, etc.
> > > (e) warnings and errors ("declare error", "declare warning")
> > > -Would you want to search for these? One category or two? What kind of
> > > restrictions might make sense?
> > Quite likely, but not necessarily.
> > > (f) softened exceptions ("declare soft")
> > > -Would you want to search for these? What kind of restrictions might
make
> > > sense?
> > Yes
> > > (g) other
> > > -Now that aspectJ will be built on the eclipse compiler, some things will
> > > come to us for "free". A search for implementers on the Java Search page
> > > (once enabled), would also return aspects in the result set. Would it be
> > > useful to have an "implementers" search on the AspectJ search page that
> > > returned only aspects that implement a specified interface?
> > > -Is there anything I've missed that would be useful to search for?
> > > Should the final GUI resemble anything similar to the included
screenshot,
> > > I would expect at a minimum that the "Named" and/or "Affecting + Named"
> > > sections will be enabled/disabled as appropriate for each different type
> > > of search. Examples: (1) if "Advice" is chosen in the "Search for"
> > > section, the first "Named" will be disabled. (2) if Aspect is chosen,
> > > "Named" would be disabled, and the "Affecting" + "Named" pair would be
> > > enabled. (3) if "Pointcut is chosen, all would remain enabled.
> > > Comments and feedback most welcome.
> > > Regards,
> > > Julie Waterhouse
> > > AJDT Development Team
|
|
|
| Re: search function design [message #561925 is a reply to message #5304] |
Thu, 10 October 2002 20:06 |
Mik Kersten
Messages: 287
Registered: July 2009 |
Senior Member |
|
|
"Arno Schmidmeier" <Arno.Schmidmeier@sirius-eos.com> wrote in message
news:anu751$rih$1@rogue.oti.com...
.. . .
> > You suggest adding the elements "type, constructor, method, field and
> > package" to the AspectJ search page. This brings up the issue of how we
> > separate functionality between the AspectJ search page and the Java
search
> > page in the search dialog. Since search for those items already exists
on
> > the Java search page, I would propose leaving them there. However,
since
> > we will soon be based on the Eclipse compiler, a search for a "type"
> > should then also return aspects as well. So the Java page will have the
> > ability to search for at least that AspectJ-related object. That means
> > the line is a little blurred between the two pages. What do people
think
> > is the right solution? Do we repeat an aspect-only search on the
AspectJ
> > page? Or do we keep all type searching together in one place only on
the
> > Java page?
>
> I would suggest searching everything in one place, just the java page.
> Just because classes are nearly a total subset of aspects. (OK the
> construction issue, but you can easily work around that) ...
> My analogy:
> In an C/C++ IDE you do not have different search windows for structs and
> classes.
I agree with Arno that splitting up the AspectJ and Java parts in is
problematic since an AspectJ programmer should not need to make a conceptual
split between the two when searching. I suggest that we duplicate the Java
Search page and extend it to include AspectJ declarations. Then we can take
the more interesting search facilities that you're talking about and create
a "Crosscutting Search" page.
Borrowing from Julie's earlier message, the "AspectJ Search" would extend
the "Search For" to include the named :
- named pointcut
- inter-type declaration
- aspect (if we decide to break Type into Class and Interface)
There are some unnamed AspectJ members that could also be useful to search
if a limited scope is used (e.g. find all delcare parents in this package):
- advice
- pointcut
- declare warning/error
- declare parents
- delcare soft
In addition to the current 6 options "Limit To" should probably contain:
- before (for advice)
- after (for advice)
- around (for advice)
- message (for declare warning/error)
That last one is important for finding which declare is causing a particular
task list error or warning to show.
Everything in the "AspectJ Search" page can be searched from the sources and
does not require a compile. This isn't true for the pointcut related
searches that you're describing. Those searches are considerably different
from what users expect in a Java search, and will require a different UI.
So I think they deserve their own "Crosscutting Search" page. I also think
that we've filled up the UI real-estate on the "AspectJ Search" page.
> > Regarding your comments on searching for pointcuts, in your first use
> > case, you suggest selecting a block of code and searching for pointcuts
> > that pick out join points in that block (if I read it right). Mik, can
> > you comment on the feasibility of selecting a block of code to search in
> > this way? If that's not possible, is it easier to specify a particular
> > type, method, or field and search for pointcuts that affect it? (should
> > achieve almost the same function (not quite as specific), with a
different
> > UI).
>
> This feature is very important for refactoring. With AspectJ you do today
> refactoring in following way.
>
> 1. You select a line of code.
> 2. You look and try to find the pointcuts which may affect that block of
> code.
> and the advices of this code.
> 3. You refactor it.
> 4. You try to fix these pointcuts, so that the advices are applied in the
> correct order again.
> 2. and 4. are manually error phrone tasks, even in small and medium sized
> projects. if it gets to the large scale ist getting terrible. You start to
> think twice if you want to refactor. ...
> Tool/Search support would be of a great value.
>
> My current ultimate dream would be a fully functional aspectJ aware
> refactoring browser. But I keep on dreaming. ... ;-)
>
> > Your second pointcut use case is interesting (searching for all
pointcuts
> > that share join points with a specified pointcut, again, if I'm reading
> > you right). Mik, can you comment on the feasibility of implementing
this
> > one from an AspectJ perspective?
>
> This is from my opinon the most critical search function, because it is
> currently the most perfomed action in debugging large scale AspectJ
> projects.
I also think that the search facilities should cover what's required by
AspectJ-related refactorings. JDT's search does a good job of that for
Java. The goal is to eventually support AspectJ-aware refactorings and AO
refactorings in AJDT. But those will use similar pointcut-based searches to
the ones described above, and it would be good to expose them to the user
before we make AspectJ-specific refactorings work.
We should focus on getting the core "AspectJ Search" right first, but keep
in mind use cases like Arno's for defining the "Crosscutting Structure"
searches that we want to expose.
Mik
--
Mik Kersten
Development Tools Lead
AspectJ Team, Palo Alto Research Center
http://www.parc.com/mkersten
|
|
|
| Re: search function design [message #562139 is a reply to message #6931] |
Thu, 24 October 2002 14:10 |
Julie Waterhouse
Messages: 42
Registered: July 2009 |
Member |
|
|
I agree with Mik's suggestion of splitting search into 2 pages -- a search
page with the standard Java plus basic AspectJ extensions that can be
searched based solely on the source, and a "cross-cutting search page."
I've started with the simpler of the two, the source-based, and have
included a link to a new mockup here for discussion:
http://members.rogers.com/30159374290/searchpage2.html
Some questions/issues that came up:
"Search string" entry field:
============================
When should the search string entry field be enabled? In the original
Java search, it was always enabled, but in AspectJ, we have things to
search for that are not named.
1. For Advice, Declare Warning/Error and Declare Soft, I propose disabling
the search string entry field.
2. For inter-type declaration, I propose leaving it enabled, and allowing
the user to enter the field or method name for the introduced member. Of
course, below I was going to note that I had lumped "Declare parents"
under this category too (mostly to try and save on real estate...), but
there might be a good reason to split it out. Declare parents should
probably have the search string disabled, and just find all declarations
within the given scope. Opinions?
3. Pointcut is the tricky one (always!) because it can be named or not.
For that, we may need to do a check - leave the entry field enabled, and
if there is something in it, search for pointcuts named that, or if it's
empty, search for all pointcuts in the specified scope. Other suggestions?
What are appropriate "Limit to" restrictions for the new "Search for"
items?
============================================================ ================
1. Inter-type declaration:
We could have "Declarations" where it would find the place in the aspect
where it's defined, and "References" where it would find the class
affected. But that's moving beyond the source stuff Mik talked about
restricting this page to, and into the "cross-cutting" type of search.
So, I propose just enabling "Declarations" and having the search find all
inter-type declarations within the named scope. (Would anyone prefer
enabling only "All occurrences?")
2. Advice:
I propose enabling only "Declarations" (would catch all types - before,
after and around), "Before," "After" and "Around."
3. Declare warning/error:
I propose enabling only "Declarations" and "Message."
4. Declare soft:
I propose enabling only "Declarations."
5. Pointcut:
I propose enabling only "Declarations."
Scope:
======
Should we prevent the user from searching for all
-unnamed pointcut
-declare parents
-advice
-declare warning/error
-declare soft
in the workspace (just because the search could be so huge)? It could be
implemented such that if you select "workspace", those search options are
disabled. Only if you have something selected (e.g., a type, package or
project) before you open search will you see the option when the dialog
opens. If you switch the scope to "workspace", they'll be disabled (and
the current selection set back to "Type"). Conversely, if you go into the
dialog, with nothing selected and change the scope to "working set", the
options will become enabled.
The alternative is to allow the user to search all advice (or declare
parents, or ...) in the entire workspace.
Notes:
======
I have not separated out "Declare parents" as a separate "Search for"
item, and have assumed that those will be captured by the "inter-type
declaration" search. See above for some discussion why this might not be
a good idea -- but my dialog is getting big! If you think it should be a
separate item, then we *really* need to address real estate issues. Even
now, the dialog for the AspectJ search is longer than all the others, so
the dialog is now about 100 pixels longer that it used to be.
You may notice a bit of a hack. When the search string entry field is
disabled, you'll see a "*" in it. This is to force the Search button on
the dialog to be enabled - it's only enabled when there's something in
that entry field.
Note that there are problems with the keyboard mnemonics on this page.
"After" and "Search for" both use 'a'. "Pointcut" and "Case-sensitive"
both use 't' (this was a problem on the original Java Search dialog, where
"Type" and "Case-sensitive" both used 't'). I may be able to make them
unique, but not without changing them from the original Java page -- as I
already did with Type (which is less than desirable). I gave up on this
one 'cause it was driving me nuts ;-). 'j', 'q', and 'x' are the only
alphabetic characters not used!
Okay, that's enough for now... This is getting long!
Julie Waterhouse
AJDT Development Team
|
|
|
Goto Forum:
Current Time: Sat Dec 21 17:06:25 GMT 2024
Powered by FUDForum. Page generated in 0.04511 seconds |
] 
Search
Help
Register
Login
Home
