Community
Participate
Working Groups
I20060315-1200 An initial solution to show categories in the UI has been provided with 3.2. A nicer solution is to allow grouping of categories in [Quick] Outline view.
*** Bug 158017 has been marked as a duplicate of this bug. ***
*** Bug 141745 has been marked as a duplicate of this bug. ***
*** Bug 158374 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > I20060315-1200 > > An initial solution to show categories in the UI has been provided with 3.2. > A nicer solution is to allow grouping of categories in [Quick] Outline view. > In the end, I'd love to have a universal browsing solution that uses "facets" (tags with values). An example of well-done facet navigation is iTunes where you have facets for songs such as composer and title. If you look closely, there is quite a bit of information attached to a method that could be considered tags/facets: Visibility, static vs. non-static, annotations etc. JavaDoc's @category just adds one more dimension here. With a facet browser, one could formulate queries such as the following in a very natural way: "Give me all public methods with annotation @Remote that belong to category 'persistence'". This browser should optionally access *all* methods (of all classes) in order to serve as a universal query mechanism. It would be nice if we could at least go partially beyond trees as a structuring mechanism and allow multiple relations to be layered on top of Java entities (even if only for documentation purposes). Let me know if I should sketch my UI ideas on this.
This sounds like an excellent idea for plug-in that sits on top of Eclipse and - if it proofs useful and stable - could be integrated into the Eclipse SDK at a later point.
(In reply to comment #5) > This sounds like an excellent idea for plug-in that sits on top of Eclipse and > - if it proofs useful and stable - could be integrated into the Eclipse SDK at > a later point. Good point! Would do it myself if I had the time... :-( We have written a research prototype that improves just the outline view in two ways (so these ideas are directly relevant for the outline): - Nested methods: If a method n is private and only used by a method m, then file n under m in the hierarchy (thus, n is not visible at the top level, any more). The reasoning here is: "extract method" is a great refactoring for cleaning up code, but it unnecessarily clutters the top level of the code outline. - Method groups (this can be replaced by @category!): If a sequence of methods is preceded by a commentary //---------------- foo then these methods will be filed under a node "foo" in the hierarchy (= one additional level of nesting) This is described here: http://www.pst.ifi.lmu.de/Fopra/rauschma/2005/nepper/ For method groups, one can also view categories as tags and, instead of introducing another level of nesting, list the categories as toggle-able buttons that filter the outline: +-----------------------+ | o | x | @ | # | * | + | <-- icons +-----------------------+ | (read) (write) (sort) | <-- buttons | (init) | | | | - prepareForSorting() | <-- outline tree | - writeContents() | | ... | +-----------------------+ Thus: Selecting a button filters the outline, unselecting it undoes the filtering. Another possibility is to have filter buttons for "private", "public", "static" etc, too. This might also be *complementary* to the nesting approach.
*** Bug 159095 has been marked as a duplicate of this bug. ***
