Bug 48288 - Integrate form editor with refactoring
Integrate form editor with refactoring
Status: RESOLVED FIXED
Product: guibuilder
Classification: Unclassified
Component: Code
4.x
All All
: P1 with 27 votes (vote)
: 6.x
Assigned To: arseniy
issues@guibuilder
plan60
:
: 44267 53392 56549 59140 59628 67777 70465 70893 71570 71696 72587 75187 76326 78450 78935 80767 83722 88604 89001 91639 94594 97744 98336 103520 103891 104088 104382 (view as bug list)
Depends on:
Blocks: 62218 89585
  Show dependency treegraph
 
Reported: 2004-09-01 10:29 UTC by Jan Stola
Modified: 2008-07-15 10:19 UTC (History)
8 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Stola 2004-09-01 10:29:02 UTC
Refactoring is not well integrated with form
module. Consider for example rename of some
field generated by form editor.

The occurences outside the guarded blocks can be
renamed using Refactoring > Rename action on
the node that represents the field.
Unfortunately the .form file is not modified
and therefore the occurences in the guarded blocks
are not renamed.

The occurences inside the guarded blocks can be
renamed for example by Rename action on the
corresponding node in the Inspector, but this
action doesn't rename occurences outside
guarded blocks.

By now the user must perform both steps
(in this order) to achieve a complete rename.
Comment 1 Jan Stola 2005-01-27 13:26:48 UTC
*** Issue 53392 has been marked as a duplicate of this issue. ***
Comment 2 Vince Kraemer 2005-02-24 05:52:06 UTC
Closing a defect by marking it as a duplicate of a task is a great way
to get the bug count down.

Is there any commitment to DO this task?

This has been reported as a defect by users. See the defect that has
been closed as a duplicate of this?
Comment 3 Martin Matula 2005-02-24 09:40:47 UTC
This task definitely deserves a higher priority. IMO this is a must
have for 4.2. P3->P1
Comment 4 Tomas Pavek 2005-05-13 16:19:32 UTC
Let's target this for 4.2 - it would be really desirable to have it done.
Hopefully somebody from refactoring team will help us ;)
Comment 5 Tomas Pavek 2005-05-13 16:37:49 UTC
*** Issue 44267 has been marked as a duplicate of this issue. ***
Comment 6 Jan Stola 2005-05-27 13:09:09 UTC
*** Issue 59140 has been marked as a duplicate of this issue. ***
Comment 7 Vince Kraemer 2005-06-04 05:50:02 UTC
*** Issue 59628 has been marked as a duplicate of this issue. ***
Comment 8 Vince Kraemer 2005-06-04 05:52:00 UTC
*** Issue 59628 has been marked as a duplicate of this issue. ***
Comment 9 Vince Kraemer 2005-06-04 05:52:43 UTC
There has been a fair number of issues raised about this.  This really needs attention.

Comment 10 Jan Becicka 2005-10-20 15:16:06 UTC
This bug has 8 votes. It deserves evaluation.
Comment 11 Jan Becicka 2005-10-31 07:20:43 UTC
*** Issue 67777 has been marked as a duplicate of this issue. ***
Comment 12 Jan Stola 2005-12-02 09:47:51 UTC
As it has been already written - it would be really desirable to have it done.
Unfortunately it will not be done for NB 5.0.
Comment 13 Jan Stola 2005-12-15 14:31:32 UTC
*** Issue 70465 has been marked as a duplicate of this issue. ***
Comment 14 Jan Stola 2006-01-02 09:31:03 UTC
*** Issue 70893 has been marked as a duplicate of this issue. ***
Comment 15 rsk 2006-01-20 03:44:27 UTC
If this does not get completed soon I will fly to Prague and stand in the
NetBeans office, in my underwear, singing, until it is fixed; consider this fair
warning.





(As a hacky but workable fixed, why can't the two operations just be tied
together? Refactor Outside invokes a rename on the form after it's done and
rename inside invokes a refactor after it's done?)
Comment 16 Marek Grummich 2006-01-22 18:21:11 UTC
*** Issue 71696 has been marked as a duplicate of this issue. ***
Comment 17 Jan Stola 2006-03-23 15:22:47 UTC
*** Issue 72587 has been marked as a duplicate of this issue. ***
Comment 18 Jiri Prox 2006-07-21 09:11:06 UTC
*** Issue 80767 has been marked as a duplicate of this issue. ***
Comment 19 Tomas Pavek 2006-08-09 14:19:22 UTC
*** Issue 75187 has been marked as a duplicate of this issue. ***
Comment 20 Tomas Pavek 2006-08-09 16:50:50 UTC
*** Issue 78450 has been marked as a duplicate of this issue. ***
Comment 21 Jan Stola 2006-08-24 11:19:36 UTC
*** Issue 71570 has been marked as a duplicate of this issue. ***
Comment 22 Jan Stola 2006-08-30 09:21:29 UTC
*** Issue 83722 has been marked as a duplicate of this issue. ***
Comment 23 _ wadechandler 2006-08-30 16:34:41 UTC
Do any refactoring APIs have the ability to attach refactoring listeners and
have event firing mechanisms?  If not that would be the best solution to address
these situations not only with form, but with other modules which may be or want
to be using refactoring.
Comment 24 brviking 2006-08-30 16:43:13 UTC
Guys, a form is just a XML file. Sourced on this xml file, the .java file is
created (or merged?).
So what is difficulty for write a refactoring module that is able to deal with
forms?
Indeed, JackPot need to deal with this situation too. What's planned for?
Comment 25 Martin Matula 2006-08-30 17:05:16 UTC
I don't think plugging into an existing refactoring is an issue - it is very
easy. :)
Comment 26 _ wadechandler 2006-08-30 19:12:34 UTC
>I don't think plugging into an existing refactoring is an issue - it is very
>easy. :)

Apparently I'm missing something, because the issue seems to be related to just
this, and then there is a comment from Tomas about getting help from the
refactoring team.  In the current documentation at platform.netbeans.org there
is the RefactoringActionsFactory (which I assume should be firing actions for
this issue):

http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-refactoring/org/netbeans/modules/refactoring/api/ui/RefactoringActionsFactory.html

I then see in refactorings there is an SPI for refactorings, but I do not see
any services in the form sources.  I would think form could implement
org.netbeans.modules.refactoring.spi.SimpleRefactoringElementImpl SPI, but it
doesn't, so I'm trying to figure out why not, and if I am missing other things
to the puzzle here as to how to tie into refactoring.  The poor documentation
(at least the documentation I can find) on the refactoring SPI and API doesn't
help however.
Comment 27 Martin Matula 2006-08-30 22:08:51 UTC
Look at the Refactoring API/SPI overview:
http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-refactoring/overview-summary.html

In the use-case section for SPI there is a short overview of how to plug in a
functionality for a refactoring.
In case of Form editor, it would probably be best to implement
GuardedBlockHandler/-Factory from the spi package (better description of those
classes would be desirable).
As I said, plugging something in is pretty simple. But the implementation of
that something (i.e. replacing the right pieces of the XML file representing the
Form metadata) may be tricky - that's the core of what the Form team needs to
implement.

I guess the reason why you don't see any implementation of refactoring SPI in
Form is it is not integrated with the refactoring right now - that's what this
issue is all about, right?
Comment 28 _ wadechandler 2006-08-31 00:27:29 UTC
Well, the issue says:
"Refactoring is not well integrated with form module"
, but I don't think it is integrated at all, and was partially contributing to
my confusion.  It has only refactoring support built in partially to the form
module itself and only the areas it specifically defines them, but there is no
integration at all with the rest of the system.  That is what I was wanting to
make sure the case was.  I'm pretty sure it isn't integrated at all currently. 
Unless there is some other means (other than refactoring SPI) in which the
platform can send events or actions for refactoring and the form module is
listening to these actions.  That is partially why I posted before whether there
was an API in refactoring modules could register.  Anyways, I'm assuming the
only way to hook into refactoring is to use the SPI and since form doesn't
define any services then it does not integrate at "all" currently with refactoring.

On the subject of Jackpot and this issue or ones like it in general.  Is there
going to be another API for refactoring, or does Jackpot currently use the
refactoring APIs and this will continue to be used?  Is Jackpot going to define
another API which could be better utilized and will become part of the platform?
 I assume the Java Model is going to be changed to use the new compiler JSR per
Tim's interview at artima.  Anything anyone should be looking at here for future
use and relation to this issue?
Comment 29 _ wadechandler 2006-08-31 00:55:36 UTC
Just read over JSR 199 APIs.  I guess I don't see how it would affect
refactoring except maybe behind the scenes leaving the interface to the
refactoring API the same, so unless Jackpot adds any new refactoring APIs then I
guess I answered my own question.
Comment 30 _ wadechandler 2006-08-31 01:10:26 UTC
Tomas or anyone else from the form project.  Is anyone working on this issue
currently, or would it be marked as such (started or assigned to a name) were it
started?  I might start add a couple of things to code from the trunk and see
about a patch or something.  Maybe just the basic needs.  Dealing with class and
variable renaming.
Comment 31 Jan Stola 2006-08-31 08:50:58 UTC
> Is anyone working on this issue currently, or would it be marked as such
>(started or assigned to a name) were it started?

No, nobody is working on this issue by now. The main reason are resource 
problems and big deal of uncertainty about changes in java infrastructure. As 
for the first reason - we understand to the importance of this issue, but it is 
a big deal of work and we simply don't have enough resources to implement it, 
by now. As for the second reason - it is not clear how the refactoring APIs 
will be affected by the new java infrastructure. Sure, it may (and hopefully 
will) happen that the APIs will remain the same, but the APIs are not all. For 
example, the current java infrastructure has many rules how this or that should 
be accomplished and these rules are not well (or at all, if you prefer ;-)) 
documented. I am sure that these rules will not stay the same :-(.

> I might start add a couple of things to code from the trunk and see
> about a patch or something.  Maybe just the basic needs.  Dealing
> with class and variable renaming.

It would be great, definitely.
Comment 32 Jan Stola 2006-08-31 09:14:14 UTC
*** Issue 78935 has been marked as a duplicate of this issue. ***
Comment 33 _ wadechandler 2006-11-07 03:33:47 UTC
*** Issue 88604 has been marked as a duplicate of this issue. ***
Comment 34 Tomas Pavek 2006-11-09 09:34:52 UTC
*** Issue 88604 has been marked as a duplicate of this issue. ***
Comment 35 _ wadechandler 2006-11-09 14:19:01 UTC
Just for note: I'm waiting on the new 6.0 Java infrastructure and it to be
stabilized before attempting to work on this.  If someone else is working on
this or planning on it let me know and I will not bother.  I'll mark it as
started if and when I get to it just waiting on 6.0, and I do not plan on back
porting, but once I get it into 6.0 it might not be such a hard thing depending
on the API changes...we'll just have to see.
Comment 36 Jan Becicka 2006-11-22 12:51:22 UTC
*** Issue 89001 has been marked as a duplicate of this issue. ***
Comment 37 Jiri Prox 2007-01-02 09:03:59 UTC
*** Issue 91639 has been marked as a duplicate of this issue. ***
Comment 38 Jan Becicka 2007-01-02 13:15:10 UTC
36 votes for this issue, 20 duplicates. P3 is not appropriate IMO.
Comment 39 twolf2919 2007-01-12 19:10:14 UTC
I just came across another problem:  I added an interface to my
Matisse-developed JPanel and took NB up on its offer to implement all the
interface's methods.  But that causes an exception in the latest (11012007)
build :-(
java.io.IOException
	at
org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:90)
	at
org.netbeans.modules.java.hints.ImplementAllAbstractMethodsCreator$FixImpl.implement(ImplementAllAbstractMethodsCreator.java:165)
	at org.netbeans.modules.editor.hints.HintsUI$1.run(HintsUI.java:498)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541)
[catch] at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963)
Caused by: org.netbeans.editor.GuardedException: Attempt to remove from guarded
block at position 26,176.
	at org.netbeans.editor.GuardedDocument.preRemoveCheck(GuardedDocument.java:188)
	at org.netbeans.editor.BaseDocument.remove(BaseDocument.java:757)
	at
org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:85)
	... 4 more
Comment 40 Tomas Pavek 2007-02-06 15:12:42 UTC
*** Issue 94594 has been marked as a duplicate of this issue. ***
Comment 41 arseniy 2007-03-05 15:56:09 UTC
we should try to fix this for 6.0
Comment 42 Jiri Prox 2007-03-13 15:55:43 UTC
*** Issue 97744 has been marked as a duplicate of this issue. ***
Comment 43 Jan Stola 2007-03-20 14:43:09 UTC
*** Issue 98336 has been marked as a duplicate of this issue. ***
Comment 44 arseniy 2007-04-18 11:26:19 UTC
*** Issue 76326 has been marked as a duplicate of this issue. ***
Comment 45 arseniy 2007-04-19 13:40:17 UTC
this is new functionality, changing issue type to be clear on that. 
it's planned for M10.
Comment 46 santafen 2007-04-19 13:42:12 UTC
I *SO* don't agree that this is a new feature. Since when is correct functionality a new feature?? Unless it's 
just a way to close bugs ...
Comment 47 Vince Kraemer 2007-04-19 16:43:01 UTC
Glad to see that you are taking this issue on.
Comment 48 _ wadechandler 2007-04-19 17:44:42 UTC
santafen, who said it is closed. It has a priority of P1 and will be worked on
soon. The goal is to have it in NB 6.0.
Comment 49 santafen 2007-04-19 17:59:48 UTC
It is now a P1 *feature* not a P1 *bug*. As I said, fixing something to work correctly is usually not 
considered a 'feature' but rather a bug fix. Semantics, I grant you, but rather important. 

Having rename/refactor work correctly is, I guess, in some odd way, a feature.

I also don't believe that this bug addresses the issue I raised in <http://www.netbeans.org/issues/
show_bug.cgi?id=76326> in that this issue only addresses form elements, not Bundle resource elements, 
but I'll wait to see if they are addressed together.
Comment 50 Jiri Prox 2007-05-09 10:57:08 UTC
*** Issue 103520 has been marked as a duplicate of this issue. ***
Comment 51 Jiri Prox 2007-05-14 10:32:44 UTC
*** Issue 103891 has been marked as a duplicate of this issue. ***
Comment 52 Jiri Prox 2007-05-17 10:25:29 UTC
*** Issue 104088 has been marked as a duplicate of this issue. ***
Comment 53 Jana Maleckova 2007-05-21 10:59:44 UTC
*** Issue 104382 has been marked as a duplicate of this issue. ***
Comment 54 Tomas Pavek 2007-06-15 15:47:23 UTC
So hopefully some good news: We've implemented the main refactoring scenarios in GUI builder. Should appear in trunk
builds on Monday. Obviously we were not able to do everything at once, but the most typical use cases should be covered
(should be a huge difference from _nothing_ as it was so far). These are the implemented scenarios:

- Renaming a component variable
- Renaming/moving a component class (being used in GUI forms)
- Renaming/moving the form class itself
- Renaming a package

The changes also include updating the internationalization keys, moving/renaming properties files, resources for the new
Swing App Framework (JSR-296), and all changes fully support undo.

For more details see:
http://wiki.netbeans.org/wiki/view/GUIBuilderRefactoring

For the rest of the unsupported scenarios I've created issue 106831. Subscribe to this issue if you are interested in
further progress in the future. Also if you find some of the duplicates here (48288) still not implemented, please
reassign it under the new issue.

Marking as fixed.
Comment 55 Jan Becicka 2007-06-25 19:59:55 UTC
*** Issue 108063 has been marked as a duplicate of this issue. ***
Comment 56 Tomas Pavek 2008-03-25 18:57:09 UTC
*** Issue 56549 has been marked as a duplicate of this issue. ***
Comment 57 Tomas Pavek 2008-07-15 10:19:22 UTC
*** Issue 73111 has been marked as a duplicate of this issue. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo