| AW: [ajdt-dev] Re: search function design |
I like to drop some of my considerations.
I hope they are usefull.
Cheers
Arno
> -----Ursprüngliche Nachricht-----
> Von: juliew@xxxxxxxxxx [mailto:juliew@xxxxxxxxxx]
> Gesendet: Donnerstag, 24. Oktober 2002 16:49
> An: ajdt-dev@xxxxxxxxxxxxxxx
> Betreff: [ajdt-dev] Re: search function design
>
>
> 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.
>
I do not agree here. the search string field is the only element, where I can narrow my search realistically.
> 1. For Advice, Declare Warning/Error and Declare Soft, I
> propose disabling
> the search string entry field.
You will normall have plenty of advices. so listing them all, is IMHO not the best idea. I suggest to use the search string as a subpart of the pointcut declaration.
e.g.
having something like
*execution* should find:
before():execution(...){
and
before(): MyexecutionPointcuts()
declare warning/error soft is pretty close the same. But match the search string
field additionally against the warning string.
>
> 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?
>
Do a pattern match against the pointcut name and the pointcut definition.
With this approach you can search after both.
What we need is an escape sequence for wildcards in the patterns.
I suggest \* for a * in the pointcuts.
>
> 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.
As soon as the AspectJ projects gets bigger, with more AspectJ elements in them,
we have the same even inside a project.
From my understanding we should use the search string for the limitation.
>
>
> 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!
Then simply drop some keyboard mnemonics on this page. Drop first in the limit to section.
>
> Okay, that's enough for now... This is getting long!
>
> Julie Waterhouse
> AJDT Development Team
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/ajdt-dev
>