Bug 69486 - [projection] Smart getter/setter/propertychange code folding
Summary: [projection] Smart getter/setter/propertychange code folding
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 enhancement with 6 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 63391 212845 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-07 12:05 EDT by David J. Orme CLA
Modified: 2007-12-13 02:31 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David J. Orme CLA 2004-07-07 12:05:30 EDT
When Platform/Text detects a field plus a getter plus a setter grouped together,
there should be an option to fold the entire JavaBean property down to one
line--probably the first line present.

This should be intelligent so that if a property is bound or vetoable (has
property change support), that will be folded in as well.

This would make the code folding much more useful to me (not that I dislike it
now) and would make my code much more readable as a result.
Comment 1 David J. Orme CLA 2004-07-07 12:06:24 EDT
s/Platform\/Text/JDT\/Text/g;
Comment 2 Adam Kiezun CLA 2004-07-07 17:12:53 EDT
fyi, the platform text layer knows _nothing_ about java beans. it only 
understands text.
even jdt text knows nothing about java beans - it only understands standard 
java.
this request should really be entered against a component that does understand 
java beans - but i think there is currently none in eclipse sdk.
Comment 3 David J. Orme CLA 2004-07-07 17:37:18 EDT
Adam,

Please note my request to substiture JDT/Text for Platform/Text and the fact
that the bug is logged against JDT/Text.

Allowing navigation and editing of higher-level conceptual constructs than the
bare Java code is one of the features that makes the JDT stand out from other
IDEs.  For example, this is the whole purpose of the refactoring and
template-based editing features.  Extending this support to Java Beans is just a
natural evolution of what Eclipse has been doing all along.

With EJB3 moving to a Java Beans model + metadata annotations, this is also in
keeping with the direction that Java itself is evolving.

This is one of several bugs I've logged in this same vein.  See also bug 26618
and bug 55763.

Comment 4 David J. Orme CLA 2004-07-07 17:42:10 EDT
Maybe JDT/UI should own this?  I'll let someone else make the call...
Comment 5 Dani Megert CLA 2004-07-08 04:33:59 EDT
Getters and setters might not be grouped together and hence sinmple folding
would not do the trick.
Comment 6 David J. Orme CLA 2004-07-08 09:17:53 EDT
Added property change support to the summary as per my initial comment (don't
want that part of the JavaBeans spec to get lost/unsupported and it was in my
original request).

Comment 7 Nathan Blomquist CLA 2004-07-17 00:12:01 EDT
Maybe to solve this we could use some sort of comment-tag solution.  Example:

// region<myField>
public String getMyField(){
return myField;
}

public void setMyField(String t){
myField = t;
}
// endregion<myField>

everything between region and endregion would be folded.  This would be sort of
like C#'s regions and would since I have the comment '//'s then this won't
intefere or need a compiler change only an IDE that supports these comment
tags... sort of like javadoc.
Comment 8 David J. Orme CLA 2004-07-17 23:23:57 EDT
If you want comment-based folding, I'd support that, but that's a different
subject than the one I brought up here.  JDT has enough metadata to be able to
detect these things without inserting comments into the code, so I would not
favor that solution for this bug.

That solution could go it its own bug report, though, IMO.
Comment 9 Dani Megert CLA 2004-07-19 06:11:14 EDT
agree with comment 8
Comment 10 Dani Megert CLA 2007-12-13 02:31:42 EST
*** Bug 212845 has been marked as a duplicate of this bug. ***
Comment 11 Dani Megert CLA 2007-12-13 02:31:48 EST
*** Bug 63391 has been marked as a duplicate of this bug. ***