Bug 45137 - DataLoader setActions() should consume javax.swing.Actions
DataLoader setActions() should consume javax.swing.Actions
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Data Systems
4.x
All All
: P2 (vote)
: 4.x
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
: 53615 56214 (view as bug list)
Depends on:
Blocks: 40260 48765 50317
  Show dependency treegraph
 
Reported: 2004-06-18 08:41 UTC by Petr Hrebejk
Modified: 2008-12-22 20:01 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Current version - everything works but the serialization (11.86 KB, patch)
2004-06-18 14:37 UTC, Jaroslav Tulach
Details | Diff
Declarative approach that uses layers (27.81 KB, patch)
2004-07-04 01:29 UTC, Jaroslav Tulach
Details | Diff
Declarative approach that fully keeps backward compatibility (38.80 KB, patch)
2004-08-01 20:33 UTC, Jaroslav Tulach
Details | Diff
New patch with changes to openide,core,java and refactoring modules (76.16 KB, patch)
2004-11-08 08:30 UTC, Jaroslav Tulach
Details | Diff
Improvements for the FormDataNode, however the code is still as fragile as it was - e.g. it continues to make the same dangerous assumptions about the result of javaLoader.getActions() (2.19 KB, patch)
2004-11-09 07:00 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hrebejk 2004-06-18 08:41:09 UTC
The DataLoader.setAction( SystemAction[] ) method
did not reflect the move of actions from
SystemActions to javax.swing.Actions. 
This results in lot of wrapping code in the IDE.
It would be nice to allow the method to take array
ofjavax.swing.Actions as parameter.
Comment 1 Petr Hrebejk 2004-06-18 08:42:22 UTC
Fixing Summary
Comment 2 Jaroslav Tulach 2004-06-18 14:19:12 UTC
I've just faced the first problem.
DataLoader.setActions(SystemAction[]) stores the actions persistently.
Which is ok, as it is enough to just know the action's classname. But
what should be done with javax.swing.Action?

First thought: If not serializable, skip them. If serializable
serialize them. Does not work well, as javax.swing.AbstractAction is
serializable and thus most of the actions are serializable by default.
That would lead to problems. That is for sure.
Comment 3 Jaroslav Tulach 2004-06-18 14:37:34 UTC
Created attachment 15831 [details]
Current version - everything works but the serialization
Comment 4 Jaroslav Tulach 2004-07-04 01:29:09 UTC
Created attachment 16132 [details]
Declarative approach that uses layers
Comment 5 Jaroslav Tulach 2004-07-04 01:39:09 UTC
I guess that this second approach might solve all the troubles. The
actions are read from a folder on disk which name is provided by
String DataLoader.actionsContext() which defaults in case of java to 

org-openide-loaders/org-netbeans-modules-java-JavaDataLoader/Actions

but can of course be overriden to point anywhere. Basically your
modules (java, projects, refactoring) need to create all the actions
in layer and do not even touch DataLoader.setActions.

More or less this is ready to be commited. The only obsticles  that
may cause problems and I am aware of are backward compatibility with
existing loaders (right now I just create all the files in
actionsContext() folder as soon as getActions() is called based on the
content returned from defaultActions() method) and the UI in
Tools/Options that allows customizations. It would likely need a bit
of rewrite after this change (otherwise I am affraid user would not be
able to manipulate with non SystemActions).

I am reassigning this to Hrebejk to give it a try and evaluate the
usefulness of implementing this.
Comment 6 Petr Hrebejk 2004-07-29 16:04:42 UTC
As Yarda pointed out there are better ways how to improve the
performance of the Project actions. So maybe we should not integrated
this in the D time frame. Good candidate for the next release though.
Comment 7 Jaroslav Tulach 2004-08-01 20:33:55 UTC
Created attachment 16593 [details]
Declarative approach that fully keeps backward compatibility
Comment 8 Jaroslav Tulach 2004-08-01 20:42:46 UTC
After discussions with Hrebejk and others we have concluded that it
makes sence to provide a way how loaders can read their actions from a
certain location in a layer. However we decided that this should be an
extension behaviour, not being turned on by default. That is why there
is new protected method String actionsContext() that by default return
null, but can be overriden to instruct the loader to take its actions
from the layers. If not overriden everything is supposed to behave as
it did until now.

I am confident about quality of my code (well, two-three days of bug
fixing may be needed), so I am ready to commit immediatelly, but as
Hrebejk's problem may have another fix, Matula keeps his silence and
there would be some work needed by the java module (well override
actionsContext and define its actions there ;-), I now plan to
integrate this for promo-E and I am no longer threating this as a defect.
Comment 9 _ rkubacki 2004-09-02 08:27:43 UTC
The hack implemented in JavaProjectModule is now in WebProjectModule
too where JspDO and HtmlDO functionality is extended. I agree we
should do it for promo-E. (don't we miss API keyword here?)
Comment 10 Jesse Glick 2004-09-04 08:30:07 UTC
Cool!

Probably also need to rewrite the action customizer set by
DataLoaderBeanInfo and used in the Object Types subnodes in the
Options dialog, which assumes SystemAction's.

Also compare David Strupl's openidex/enode which solves this kind of
problem more generally for any node incl. actions, lookup, and icons.
Of course Looks would solve it even more generally, but we have to
stop fantasizing at some point and actually put something workable
into a real release. :-)
Comment 11 Jaroslav Tulach 2004-09-06 07:23:53 UTC
No need to compare with enode, I have stolen its tests when I started.
 
My goal was to solve the setAction problem as simply as possible, I
did not want to get into the complexities of rewriting completely
everything. However, I kept in mind the future compatibility of my
solution and I believe that if we switch to enode or looks in future
we can maintain the action registration contract because both looks
and enode support reading of actions from layer, we just need to keep
the same locations.
Comment 12 _ rkubacki 2004-11-01 13:25:53 UTC
While testing this patch I found that loader using this declarative
approach is serialized. The DataLdrActions (folder instance) calls
DataLoader.setSwingActions and here property change event is fired
that causes later serialization. This probably should be fixed before
integration.
Comment 13 Jaroslav Tulach 2004-11-08 08:30:08 UTC
Created attachment 18781 [details]
New patch with changes to openide,core,java and refactoring modules
Comment 14 Jaroslav Tulach 2004-11-08 15:27:48 UTC
I have find out this issue has not been reviewed yet. So let's start
the review.

The previous diff is a good way to show how the thing should work.
There is just one problem I am aware of and that is FormDataLoader
having different actions than JavaDataLoader while subclassing it. I
think the immediate solution is to write:

String JavaDataLoader.actionsContext () {
  if (getClass () == JavaDataLoader.class) {
    return "Loaders/text/x-java/Actions";
  } else {
    return null;
  }
}

which will retain the compatibility for FormDataLoader till all the
actions registered in the layer continue to be SystemActions (are now)
if that changes (and that is the goal) the FormDataLoader needs to be
rewritten and its "enhancing" code moved to FormDataNode. To delegate
to getActions(boolean) and "enhance" the actions array there. Or the
form can overide actionsContext() and let any other module to register
specific actions to its own context - completely free itself from
depence on java actions with all the pros and cons. 

Anyway I believe the patch is ready to be applied (works the same way
as 4.0 in Tools/Option/Object Types), before integration I plan to add
bunch of arch-*.xml documentations to describe all the new layer APIs
that are being introduced.

Please review.
Comment 15 Tomas Pavek 2004-11-08 16:44:37 UTC
I agree the "enhancing" code in form editor could be moved to
FormDataNode. Don't think the second option - providing its own
context - is usable. I just think we should be sure that customizing
the actions in FormDataNode really works (should not be a problem to
rewrite this) before integrating the patch.
Comment 16 Jaroslav Tulach 2004-11-09 07:00:55 UTC
Created attachment 18792 [details]
Improvements for the FormDataNode, however the code is still as fragile as it was - e.g. it continues to make the same dangerous assumptions about the result of javaLoader.getActions()
Comment 17 Tomas Pavek 2004-11-09 08:22:19 UTC
Looks good, thanks.
Comment 18 Jaroslav Tulach 2004-11-22 07:01:01 UTC
I'll integrate this tommorow.
Comment 19 Jaroslav Tulach 2004-11-23 09:23:47 UTC
~/work$ cvs -q ci -m "#45137: DataLoader actions can be read from a
layer" openide core java refactoring projects
Checking in openide/arch/arch-openide-datasystems.xml;
/cvs/openide/arch/arch-openide-datasystems.xml,v  <-- 
arch-openide-datasystems.xml
new revision: 1.23; previous revision: 1.22
done
Processing log script arguments...
More commits to come...
Checking in openide/loaders/manifest.mf;
/cvs/openide/loaders/manifest.mf,v  <--  manifest.mf
new revision: 1.17; previous revision: 1.16
done
Processing log script arguments...
More commits to come...
Checking in openide/loaders/api/apichanges.xml;
/cvs/openide/loaders/api/apichanges.xml,v  <--  apichanges.xml
new revision: 1.11; previous revision: 1.10
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/openide/loaders/src/org/openide/loaders/DataLdrActions.java,v
done
Checking in openide/loaders/src/org/openide/loaders/DataLdrActions.java;
/cvs/openide/loaders/src/org/openide/loaders/DataLdrActions.java,v 
<--  DataLdrActions.java
initial revision: 1.1
done
Checking in openide/loaders/src/org/openide/loaders/DataLoader.java;
/cvs/openide/loaders/src/org/openide/loaders/DataLoader.java,v  <-- 
DataLoader.java
new revision: 1.7; previous revision: 1.6
done
Checking in openide/loaders/src/org/openide/loaders/DataLoaderPool.java;
/cvs/openide/loaders/src/org/openide/loaders/DataLoaderPool.java,v 
<--  DataLoaderPool.java
new revision: 1.16; previous revision: 1.15
done
Checking in openide/loaders/src/org/openide/loaders/DataNode.java;
/cvs/openide/loaders/src/org/openide/loaders/DataNode.java,v  <-- 
DataNode.java
new revision: 1.17; previous revision: 1.16
done
Processing log script arguments...
More commits to come...
Checking in
openide/src/org/openide/explorer/propertysheet/PropertySheet.java;
/cvs/openide/src/org/openide/explorer/propertysheet/PropertySheet.java,v
 <--  PropertySheet.java
new revision: 1.166; previous revision: 1.165
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsCompatibilityTest.java,v
done
Checking in
openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsCompatibilityTest.java;
/cvs/openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsCompatibilityTest.java,v
 <--  DataLoaderGetActionsCompatibilityTest.java
initial revision: 1.1
done
RCS file:
/cvs/openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsTest.java,v
done
Checking in
openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsTest.java;
/cvs/openide/test/unit/src/org/openide/loaders/DataLoaderGetActionsTest.java,v
 <--  DataLoaderGetActionsTest.java
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in core/src/org/netbeans/core/LoaderPoolNode.java;
/cvs/core/src/org/netbeans/core/LoaderPoolNode.java,v  <-- 
LoaderPoolNode.java
new revision: 1.77; previous revision: 1.76
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/core/test/unit/src/org/netbeans/core/LoaderPoolNodeTest.java,v
done
Checking in core/test/unit/src/org/netbeans/core/LoaderPoolNodeTest.java;
/cvs/core/test/unit/src/org/netbeans/core/LoaderPoolNodeTest.java,v 
<--  LoaderPoolNodeTest.java
initial revision: 1.1
done
Processing log script arguments...
More commits to come...
Checking in core/ui/src/org/netbeans/core/ui/resources/layer.xml;
/cvs/core/ui/src/org/netbeans/core/ui/resources/layer.xml,v  <-- 
layer.xml
new revision: 1.85; previous revision: 1.84
done
Processing log script arguments...
More commits to come...
Checking in java/manifest.mf;
/cvs/java/manifest.mf,v  <--  manifest.mf
new revision: 1.82; previous revision: 1.81
done
Processing log script arguments...
More commits to come...
Checking in java/arch/arch-java.xml;
/cvs/java/arch/arch-java.xml,v  <--  arch-java.xml
new revision: 1.7; previous revision: 1.6
done
Processing log script arguments...
More commits to come...
Checking in java/nbproject/project.xml;
/cvs/java/nbproject/project.xml,v  <--  project.xml
new revision: 1.9; previous revision: 1.8
done
Processing log script arguments...
More commits to come...
Checking in java/project/manifest.mf;
/cvs/java/project/manifest.mf,v  <--  manifest.mf
new revision: 1.10; previous revision: 1.9
done
Processing log script arguments...
More commits to come...
Checking in
java/project/src/org/netbeans/modules/java/project/JavaProjectModule.java;
/cvs/java/project/src/org/netbeans/modules/java/project/JavaProjectModule.java,v
 <--  JavaProjectModule.java
new revision: 1.5; previous revision: 1.4
done
Checking in java/project/src/org/netbeans/modules/java/project/layer.xml;
/cvs/java/project/src/org/netbeans/modules/java/project/layer.xml,v 
<--  layer.xml
new revision: 1.14; previous revision: 1.13
done
Processing log script arguments...
More commits to come...
Checking in java/src/org/netbeans/modules/java/JavaDataLoader.java;
/cvs/java/src/org/netbeans/modules/java/JavaDataLoader.java,v  <-- 
JavaDataLoader.java
new revision: 1.73; previous revision: 1.72
done
Processing log script arguments...
More commits to come...
Checking in java/src/org/netbeans/modules/java/resources/mf-layer.xml;
/cvs/java/src/org/netbeans/modules/java/resources/mf-layer.xml,v  <--
 mf-layer.xml
new revision: 1.52; previous revision: 1.51
done
Processing log script arguments...
More commits to come...
Checking in refactoring/arch/arch-refactoring.xml;
/cvs/refactoring/arch/arch-refactoring.xml,v  <--  arch-refactoring.xml
new revision: 1.6; previous revision: 1.5
done
Processing log script arguments...
More commits to come...
Checking in refactoring/nbproject/project.xml;
/cvs/refactoring/nbproject/project.xml,v  <--  project.xml
new revision: 1.9; previous revision: 1.8
done
Processing log script arguments...
More commits to come...
Checking in
refactoring/src/org/netbeans/modules/refactoring/RefactoringModule.java;
/cvs/refactoring/src/org/netbeans/modules/refactoring/RefactoringModule.java,v
 <--  RefactoringModule.java
new revision: 1.5; previous revision: 1.4
done
Processing log script arguments...
More commits to come...
Checking in
refactoring/src/org/netbeans/modules/refactoring/resources/mf-layer.xml;
/cvs/refactoring/src/org/netbeans/modules/refactoring/resources/mf-layer.xml,v
 <--  mf-layer.xml
new revision: 1.16; previous revision: 1.15
done
Processing log script arguments...
More commits to come...
Checking in projects/projectui/arch.xml;
/cvs/projects/projectui/arch.xml,v  <--  arch.xml
new revision: 1.4; previous revision: 1.3
done
Processing log script arguments...
More commits to come...
Checking in
projects/projectui/src/org/netbeans/modules/project/ui/Hacks.java;
/cvs/projects/projectui/src/org/netbeans/modules/project/ui/Hacks.java,v
 <--  Hacks.java
new revision: 1.16; previous revision: 1.15
done
Processing log script arguments...
More commits to come...
Checking in
projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml;
/cvs/projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml,v
 <--  layer.xml
new revision: 1.44; previous revision: 1.43
done
Comment 20 Jaroslav Tulach 2004-11-23 09:24:50 UTC
Tomas, please integrate the change in form, so Hrebejk can stop using
SystemActions for java files.
Comment 21 Jesse Glick 2004-11-24 16:06:07 UTC
Is there some issue filed for refactoring actions to be properly
registered in the layer now?
Comment 22 Martin Matula 2004-11-24 16:14:34 UTC
To Jesse: I think it is covered by issue 50317.
Comment 23 Jaroslav Tulach 2004-11-24 16:24:00 UTC
Guys, I guess that I fixed the refactoring actions in my commit. Check
the log.
Comment 24 Martin Matula 2004-11-24 16:33:55 UTC
You are right. Thanks!
Comment 25 Jaroslav Tulach 2005-01-25 06:49:15 UTC
*** Issue 53615 has been marked as a duplicate of this issue. ***
Comment 26 Jaroslav Tulach 2005-03-11 17:32:35 UTC
*** Issue 56214 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