mbien commented on code in PR #23:
URL:
https://github.com/apache/netbeans-antora-tutorials/pull/23#discussion_r2476046771
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -315,82 +318,81 @@ You now have a skeleton `TopComponent` - a singleton
component called `MyViewerT
=== Creating a Context Sensitive TopComponent
-Click its Design tab of the open `MyViewerTopComponent` to access the
"Matisse" GUI Builder (also known as the "form editor").
-
-You will add two labels to the component, which will display some information
about the selected `Event` if there is one.
-
-
-[start=1]
-1. Drag two Labels (javax.swing.JLabel) to the form from the Palette
(kbd:[Ctrl+Shift+8]), one below the other, as shown below:
-
-image::tutorials/selection-1_viewer6.png[]
+Click the Design tab to open the "Matisse" GUI Builder (the form editor).
You'll add two labels to display information
+about the selected `Event`.
-Press F2 on the first label and then change the text as shown above, so that
by default it displays "[Nothing selected]".
-image::tutorials/selection-1_viewer7.png[]
+1. Drag two Labels (javax.swing.JLabel) from the Palette to the form, one
below the other:
++
+image::tutorials/selection-1_nb27_viewer6.png[]
++
+Select the first label and press F2, change the text to `[Nothing selected]`
as shown above.
-[start=2]
-1. Click the Source button in the editor toolbar to switch to the code editor.
Modify the signature of the class, so that `MyViewerTopComponent` implements
`LookupListener`:
-
+2. Click the Source button to switch to the code editor. Change the class
signature so `MyViewerTopComponent` implements
+`LookupListener`:
++
[source,java]
----
-public final class MyViewerTopComponent extends TopComponent implements
LookupListener {
-----
-
-Right-click in the editor and choose Fix Imports, so that `LookupListener` is
imported.
-
-Put the cursor over the lightbulb icon should appear in the editor margin. A
popup hint should appear, as shown below:
-
-image::tutorials/selection-1_viewer8.png[]
-
-Left click on the lightbulb icon in the editor margin, and when the popup
appears, select the text "Implement all abstract methods".
-
-image::tutorials/selection-1_viewer9.png[]
-
-You now have a class that implements `LookupListener` (i.e. the
`resultChanged` method). Now it needs something to listen to.
-
-There is a convenient global `Lookup` object, which proxies the Lookup of
whatever component has focus - it can be obtained from the call
`Utilities.actionsGlobalContext()`. So rather than tracking what component has
focus yourself, you can listen to this one global selection `Lookup`, which
will fire appropriate changes whenever focus changes.
-
-
-[start=3]
-1. Edit the source code of the `MyViewerTopComponent` to add a lookup result
member, and so that its `componentOpened`, `componentClosed`, and
`resultChanged` methods are as follows:
-
-
+public final class MyViewerTopComponent extends TopComponent implements
LookupListener
+----
++
+Right-click in the editor and choose Fix Imports to import `LookupListener`.
++
+A lightbulb icon will appear in the editor margin. Click it to see the popup:
++
+image::tutorials/selection-1_nb27_viewer8.png[]
++
+Select the text "Implement all abstract methods" on the context menu that
appears. Now you have a class that implements
+`LookupListener` (it implements the `resultChanged` method). You need
something to listen to.
++
+There's a global `Lookup` object that proxies the Lookup of whatever component
has focus - you can get it by calling
+`Utilities.actionsGlobalContext()`. Instead of tracking focus yourself, you
can listen to this global selection
+`Lookup`, which fires changes whenever focus changes.
+
+
+3. Edit the `MyViewerTopComponent` source to add a lookup result member and
implement the `componentOpened`,
+`componentClosed`, and `resultChanged` methods:
++
[source,java]
----
- private Lookup.Result<Event> result = null;
+private Lookup.Result<Event> result = null;
- @Override
- public void componentOpened() {
- result = Utilities.actionsGlobalContext().lookupResult(Event.class);
- result.addLookupListener (this);
- }
+@Override
+public void componentOpened() {
+ result = Utilities.actionsGlobalContext().lookupResult(Event.class);
+ result.addLookupListener (this);
+}
- @Override
- public void componentClosed() {
- result.removeLookupListener(this);
- }
+@Override
+public void componentClosed() {
+ result.removeLookupListener(this);
+}
- @Override
- public void resultChanged(LookupEvent lookupEvent) {
- Collection<? extends Event> allEvents = result.allInstances();
- if (!allEvents.isEmpty()) {
- Event event = allEvents.iterator().next();
- jLabel1.setText(Integer.toString(event.getIndex()));
- jLabel2.setText(event.getDate().toString());
- } else {
- jLabel1.setText("[Nothing selected]");
- jLabel2.setText("");
- }
+@Override
+public void resultChanged(LookupEvent lookupEvent) {
+ Collection<? extends Event> allEvents = result.allInstances();
+ if (!allEvents.isEmpty()) {
+ Event event = allEvents.iterator().next();
+ jLabel1.setText(Integer.toString(event.getIndex()));
+ jLabel2.setText(event.getDate().toString());
+ } else {
+ jLabel1.setText("[Nothing selected]");
+ jLabel2.setText("");
}
+}
----
++
+* `componentOpened()` is called whenever the component is made visible by the
window system; `componentClosed()` is
+called whenever the user clicks the X button on its tab to close it. So
whenever the component is showing, you want it
+to be tracking the selection - which is what the above code does.
+* The `resultChanged()` method is your implementation of `LookupListener`.
Whenever the selected `Event` changes, it
+will update the two `JLabel`s you put on the form.
-* `componentOpened()` is called whenever the component is made visible by the
window system; `componentClosed()` is called whenever the user clicks the X
button on its tab to close it. So whenever the component is showing, you want
it to be tracking the selection - which is what the above code does.
-* The `resultChanged()` method is your implementation of `LookupListener`.
Whenever the selected `Event` changes, it will update the two `JLabel`s you put
on the form.
-
++
The required import statements for the `MyViewerTopComponent` are as follows:
Review Comment:
nitpick: might be on the wrong indentation level. Its currently aligned
with the bullet list entries. Move one to the left?
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -503,146 +503,160 @@ import org.openide.util.NbBundle;
import org.openide.util.lookup.Lookups;
import org.openide.windows.TopComponent;
----
-
-The line `associateLookup(Lookups.singleton(obj));` will create a `Lookup`
that contains only one object - the new instance of `Event` - and assign that
`Lookup` to be what is returned by `MyEditor.getLookup()`. While this is an
artificial example, you can imagine how `Event` might represent a file, an
entity in a database, or anything else you might want to edit or view. Probably
you can also imagine one component that allows you to select or edit multiple
unique instances of `Event`, which will be the subject of the next tutorial.
-
-To make your editor component at least somewhat interesting (though it doesn't
actually edit anything), you set the text fields' values to values from the
`Event`, so you have something to display.
++
+The line `associateLookup(Lookups.singleton(obj));` creates a `Lookup`
containing one object - the new `Event` instance.
+This becomes what `MyEditor.getLookup()` returns. While this is a simple
example, you can imagine `Event` representing a
+file, database entity, or anything else you want to edit or view. You could
also have a component that lets you select
+or edit multiple `Event` instances, which is covered in the next tutorial.
++
+To make the editor component interesting (though it doesn't actually edit
anything), you set the text fields to display
+values from the `Event`.
== Running the Code
-Now you're ready to run the tutorial. Simply right click `EventManager`, the
application which contains your three modules, and choose Run from the popup
menu. When the IDE opens, simply choose Window > Open Editor to invoke your
action. Do this a couple of times, so that there are several of your editor
components open. Your singleton `MyViewer` window should also be open. Notice
how the `MyViewer` window's contents change as you click different tabs, as
shown here:
-
-image::tutorials/selection-1_result1.png[]
+Now you're ready to run the tutorial. Right click `EventManager` and choose
Run. When the IDE opens, choose
+Window > Open Editor to invoke your action. Do this a few times to open
several editor components. Your `MyViewer`
+window should also be open. Notice how the `MyViewer` window content changes
as you click different tabs:
-If you click in the Viewer window, or close all of the editor windows, note
that the text changes to "[no selection]", as shown below:
+image::tutorials/selection-1_nb27_result1.png[]
-image::tutorials/selection-1_result2.png[]
+If you click in the Viewer window or close all editor windows, the text
changes to "[no selection]".
-NOTE: If you do not see the `MyViewer` window, you probably did not check the
checkbox in the wizard to open it on system start - simply go to the Window
menu and choose MyViewer to display it.
+NOTE: If you don't see the `MyViewer` window, you probably didn't check the
"open on system start" checkbox in the
+wizard. Go to the Window menu and choose MyViewer to display it.
== So, What's the Point?
-So the key point of this tutorial is the way the code is split into three
modules: the My Viewer module knows nothing about the My Editor module, and
either one can run by itself. They only share a common dependency on My API.
That means two things: 1. My Viewer and My Editor can be developed and shipped
independently, and 2. Any module that wants to provide a different sort of
editor than My Editor can do so, and the viewer component will work perfectly
with it, as long as the replacement editor offers an instance of `Event` from
its Lookup.
-
-To really picture the value of this, imagine `Event` were something much more
complex; imagine that `MyEditor` is an image editor, and ` Event` represents an
image being edited. The thing that's powerful here is that you could replace
`MyEditor` with, say, an SVG vector-based editor, and the viewer component
(presumably showing attributes of the currently edited image) will work
transparently with that new editor. It is this model of doing things that is
the reason you can add new tools into the NetBeans IDE that work against Java
files, and they will work in different versions of NetBeans, and that you can
have an alternate editor (such as the form editor) for Java files and all the
components and actions that work against Java files still work when the form
editor is used.
+The key point is how the code is split into three modules: My Viewer knows
nothing about My Editor, and either can run
+independently. They only share a dependency on My API. This means:
-This is very much the way NetBeans works with Java and other source files-in
their case, the thing that is available from the editor's Lookup is a `
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`, and components like
Navigator and the Property Sheet are simply watching what object is being made
available by the focused `TopComponent`.
+1. My Viewer and My Editor can be developed and shipped independently
+2. Any module can provide a different editor and the viewer will work with it,
as long as the new editor offers an
+`Event` from its Lookup
-Another valuable thing about this approach is that often people are migrating
existing applications to the NetBeans Platform. The object that is part of the
data model, in that case, is probably existing, working code that should not be
changed in order to integrate it into NetBeans. By keeping the data model's API
in a separate module, the NetBeans integration can be kept separate from the
core business logic.
+To understand the value, imagine `Event` is something complex - say `MyEditor`
is an image editor and `Event` represents
+an image being edited. You could replace `MyEditor` with an SVG vector editor,
and the viewer (showing image attributes)
+would work transparently with the new editor. This is why you can add new
tools to NetBeans IDE that work with Java
+files - they work across different NetBeans versions, and alternative editors
(like the form editor) still work with all
+components and actions that work with Java files.
+This is how NetBeans IDE works with Java and other source files. The thing
available from the editor's Lookup is
Review Comment:
here too "the NetBeans IDE".
English isn't my first language but while "This is how NetBeans works"
sounds right, it starts sounding weird once the "IDE" postfix is there without
the "the" - but i could be wrong.
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -503,146 +503,160 @@ import org.openide.util.NbBundle;
import org.openide.util.lookup.Lookups;
import org.openide.windows.TopComponent;
----
-
-The line `associateLookup(Lookups.singleton(obj));` will create a `Lookup`
that contains only one object - the new instance of `Event` - and assign that
`Lookup` to be what is returned by `MyEditor.getLookup()`. While this is an
artificial example, you can imagine how `Event` might represent a file, an
entity in a database, or anything else you might want to edit or view. Probably
you can also imagine one component that allows you to select or edit multiple
unique instances of `Event`, which will be the subject of the next tutorial.
-
-To make your editor component at least somewhat interesting (though it doesn't
actually edit anything), you set the text fields' values to values from the
`Event`, so you have something to display.
++
+The line `associateLookup(Lookups.singleton(obj));` creates a `Lookup`
containing one object - the new `Event` instance.
+This becomes what `MyEditor.getLookup()` returns. While this is a simple
example, you can imagine `Event` representing a
+file, database entity, or anything else you want to edit or view. You could
also have a component that lets you select
+or edit multiple `Event` instances, which is covered in the next tutorial.
++
+To make the editor component interesting (though it doesn't actually edit
anything), you set the text fields to display
+values from the `Event`.
== Running the Code
-Now you're ready to run the tutorial. Simply right click `EventManager`, the
application which contains your three modules, and choose Run from the popup
menu. When the IDE opens, simply choose Window > Open Editor to invoke your
action. Do this a couple of times, so that there are several of your editor
components open. Your singleton `MyViewer` window should also be open. Notice
how the `MyViewer` window's contents change as you click different tabs, as
shown here:
-
-image::tutorials/selection-1_result1.png[]
+Now you're ready to run the tutorial. Right click `EventManager` and choose
Run. When the IDE opens, choose
+Window > Open Editor to invoke your action. Do this a few times to open
several editor components. Your `MyViewer`
+window should also be open. Notice how the `MyViewer` window content changes
as you click different tabs:
-If you click in the Viewer window, or close all of the editor windows, note
that the text changes to "[no selection]", as shown below:
+image::tutorials/selection-1_nb27_result1.png[]
-image::tutorials/selection-1_result2.png[]
+If you click in the Viewer window or close all editor windows, the text
changes to "[no selection]".
-NOTE: If you do not see the `MyViewer` window, you probably did not check the
checkbox in the wizard to open it on system start - simply go to the Window
menu and choose MyViewer to display it.
+NOTE: If you don't see the `MyViewer` window, you probably didn't check the
"open on system start" checkbox in the
+wizard. Go to the Window menu and choose MyViewer to display it.
== So, What's the Point?
-So the key point of this tutorial is the way the code is split into three
modules: the My Viewer module knows nothing about the My Editor module, and
either one can run by itself. They only share a common dependency on My API.
That means two things: 1. My Viewer and My Editor can be developed and shipped
independently, and 2. Any module that wants to provide a different sort of
editor than My Editor can do so, and the viewer component will work perfectly
with it, as long as the replacement editor offers an instance of `Event` from
its Lookup.
-
-To really picture the value of this, imagine `Event` were something much more
complex; imagine that `MyEditor` is an image editor, and ` Event` represents an
image being edited. The thing that's powerful here is that you could replace
`MyEditor` with, say, an SVG vector-based editor, and the viewer component
(presumably showing attributes of the currently edited image) will work
transparently with that new editor. It is this model of doing things that is
the reason you can add new tools into the NetBeans IDE that work against Java
files, and they will work in different versions of NetBeans, and that you can
have an alternate editor (such as the form editor) for Java files and all the
components and actions that work against Java files still work when the form
editor is used.
+The key point is how the code is split into three modules: My Viewer knows
nothing about My Editor, and either can run
+independently. They only share a dependency on My API. This means:
-This is very much the way NetBeans works with Java and other source files-in
their case, the thing that is available from the editor's Lookup is a `
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`, and components like
Navigator and the Property Sheet are simply watching what object is being made
available by the focused `TopComponent`.
+1. My Viewer and My Editor can be developed and shipped independently
+2. Any module can provide a different editor and the viewer will work with it,
as long as the new editor offers an
+`Event` from its Lookup
-Another valuable thing about this approach is that often people are migrating
existing applications to the NetBeans Platform. The object that is part of the
data model, in that case, is probably existing, working code that should not be
changed in order to integrate it into NetBeans. By keeping the data model's API
in a separate module, the NetBeans integration can be kept separate from the
core business logic.
+To understand the value, imagine `Event` is something complex - say `MyEditor`
is an image editor and `Event` represents
+an image being edited. You could replace `MyEditor` with an SVG vector editor,
and the viewer (showing image attributes)
+would work transparently with the new editor. This is why you can add new
tools to NetBeans IDE that work with Java
+files - they work across different NetBeans versions, and alternative editors
(like the form editor) still work with all
+components and actions that work with Java files.
+This is how NetBeans IDE works with Java and other source files. The thing
available from the editor's Lookup is
Review Comment:
`The editor's Lookup contains a
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`
might sound better
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -503,146 +503,160 @@ import org.openide.util.NbBundle;
import org.openide.util.lookup.Lookups;
import org.openide.windows.TopComponent;
----
-
-The line `associateLookup(Lookups.singleton(obj));` will create a `Lookup`
that contains only one object - the new instance of `Event` - and assign that
`Lookup` to be what is returned by `MyEditor.getLookup()`. While this is an
artificial example, you can imagine how `Event` might represent a file, an
entity in a database, or anything else you might want to edit or view. Probably
you can also imagine one component that allows you to select or edit multiple
unique instances of `Event`, which will be the subject of the next tutorial.
-
-To make your editor component at least somewhat interesting (though it doesn't
actually edit anything), you set the text fields' values to values from the
`Event`, so you have something to display.
++
+The line `associateLookup(Lookups.singleton(obj));` creates a `Lookup`
containing one object - the new `Event` instance.
+This becomes what `MyEditor.getLookup()` returns. While this is a simple
example, you can imagine `Event` representing a
+file, database entity, or anything else you want to edit or view. You could
also have a component that lets you select
+or edit multiple `Event` instances, which is covered in the next tutorial.
++
+To make the editor component interesting (though it doesn't actually edit
anything), you set the text fields to display
+values from the `Event`.
== Running the Code
-Now you're ready to run the tutorial. Simply right click `EventManager`, the
application which contains your three modules, and choose Run from the popup
menu. When the IDE opens, simply choose Window > Open Editor to invoke your
action. Do this a couple of times, so that there are several of your editor
components open. Your singleton `MyViewer` window should also be open. Notice
how the `MyViewer` window's contents change as you click different tabs, as
shown here:
-
-image::tutorials/selection-1_result1.png[]
+Now you're ready to run the tutorial. Right click `EventManager` and choose
Run. When the IDE opens, choose
+Window > Open Editor to invoke your action. Do this a few times to open
several editor components. Your `MyViewer`
+window should also be open. Notice how the `MyViewer` window content changes
as you click different tabs:
-If you click in the Viewer window, or close all of the editor windows, note
that the text changes to "[no selection]", as shown below:
+image::tutorials/selection-1_nb27_result1.png[]
-image::tutorials/selection-1_result2.png[]
+If you click in the Viewer window or close all editor windows, the text
changes to "[no selection]".
-NOTE: If you do not see the `MyViewer` window, you probably did not check the
checkbox in the wizard to open it on system start - simply go to the Window
menu and choose MyViewer to display it.
+NOTE: If you don't see the `MyViewer` window, you probably didn't check the
"open on system start" checkbox in the
+wizard. Go to the Window menu and choose MyViewer to display it.
== So, What's the Point?
-So the key point of this tutorial is the way the code is split into three
modules: the My Viewer module knows nothing about the My Editor module, and
either one can run by itself. They only share a common dependency on My API.
That means two things: 1. My Viewer and My Editor can be developed and shipped
independently, and 2. Any module that wants to provide a different sort of
editor than My Editor can do so, and the viewer component will work perfectly
with it, as long as the replacement editor offers an instance of `Event` from
its Lookup.
-
-To really picture the value of this, imagine `Event` were something much more
complex; imagine that `MyEditor` is an image editor, and ` Event` represents an
image being edited. The thing that's powerful here is that you could replace
`MyEditor` with, say, an SVG vector-based editor, and the viewer component
(presumably showing attributes of the currently edited image) will work
transparently with that new editor. It is this model of doing things that is
the reason you can add new tools into the NetBeans IDE that work against Java
files, and they will work in different versions of NetBeans, and that you can
have an alternate editor (such as the form editor) for Java files and all the
components and actions that work against Java files still work when the form
editor is used.
+The key point is how the code is split into three modules: My Viewer knows
nothing about My Editor, and either can run
+independently. They only share a dependency on My API. This means:
-This is very much the way NetBeans works with Java and other source files-in
their case, the thing that is available from the editor's Lookup is a `
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`, and components like
Navigator and the Property Sheet are simply watching what object is being made
available by the focused `TopComponent`.
+1. My Viewer and My Editor can be developed and shipped independently
+2. Any module can provide a different editor and the viewer will work with it,
as long as the new editor offers an
+`Event` from its Lookup
-Another valuable thing about this approach is that often people are migrating
existing applications to the NetBeans Platform. The object that is part of the
data model, in that case, is probably existing, working code that should not be
changed in order to integrate it into NetBeans. By keeping the data model's API
in a separate module, the NetBeans integration can be kept separate from the
core business logic.
+To understand the value, imagine `Event` is something complex - say `MyEditor`
is an image editor and `Event` represents
+an image being edited. You could replace `MyEditor` with an SVG vector editor,
and the viewer (showing image attributes)
+would work transparently with the new editor. This is why you can add new
tools to NetBeans IDE that work with Java
Review Comment:
add "the" before "NetBeans IDE"?
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -409,77 +411,77 @@ import org.openide.util.Utilities;
== Creating the Editor Component
-Now you need something to actually provide instances of `Event` for this
viewer code to be of any use. Fortunately this is quite simple.
-
-We will do this in the My Editor module, consistent with our goal of
demonstrating loose coupling between the components of our application.
-
-You will create another `TopComponent`, this time, one that opens in the
editor area and offers an instance of `Event` from its `Lookup`. You _could_
use the Window template again, but that template is designed for creating
singleton components, rather than components there can be many of. So you will
simply create a `TopComponent` subclass without the template, and an action
which will open additional ones.
-
-
-[start=1]
-1. You will need to add four dependencies to the My Editor module for it to be
able to find the classes you will be using.
-
-Right click the My Editor project and choose Properties. On the Library page
of the Project Properties dialog box, click the Add Dependency button, and type
`TopComponent` in the Filter textbox. The dialog should automatically suggest
setting a dependency on the Window System API. Do the same thing for `Lookups`
(Lookup API). Also set a dependency on the Utilities API, Base Utilities API,
and UI Utilities API, which provide various helpful supporting classes that are
made available by the NetBeans Platform.
-
-TIP: You can select more than one dependency at a time using Ctrl +
left-click. For example, you could select both Utilities API and UI Utilities
API based off a filtered search for "Utilities".
-
-You should end up with six dependencies (the MyAPI dependency from the earlier
part of this tutorial, plus the five you just added), as shown below:
-
-image::tutorials/selection-1_editor1.png[]
-
+Now you need something to provide `Event` instances for the viewer. You'll do
this in the My Editor module, keeping with
+the goal of loose coupling between components.
+
+You'll create another `TopComponent` that opens in the editor area and
provides an `Event` from its `Lookup`. The
+TopComponents are singletons by default but changing that is easy.
+
+
+1. Add dependencies to the My Editor module so it can find the classes you'll
use.
++
+Right click the My Editor project and choose Properties. On the Library page
of the Project Properties dialog box, click
+the Add Dependency button, and type `TopComponent` in the Filter textbox. The
dialog should automatically suggest
+setting a dependency on the Window System API. Do the same thing for `Lookups`
(Lookup API). Also set a dependency on
+the Utilities API, Base Utilities API, and UI Utilities API, which provide
various helpful supporting classes that are
+made available by the NetBeans Platform.
++
+TIP: You can select more than one dependency at a time using Ctrl +
left-click. For example, you could select both
+Utilities API and UI Utilities API based off a filtered search for "Utilities".
++
+You'll have six total dependencies (MyAPI from earlier, plus the five you just
added):
++
+image::tutorials/selection-1_nb27_editor1.png[]
++
You can also see these in the Libraries node of the My Editor project.
-[start=2]
-1. Right-click the `org.myorg.myeditor` package in the My Editor project, and
choose New > Other. When the New File dialog appears, select Swing GUI Forms
from the Category selection, and JPanel Form from the File Types selection.
-
-image::tutorials/selection-1_editor2.png[]
+2. Right-click the `org.myorg.myeditor` package and choose _New > Window_ like
you did for `MyViewer`. Choose `editor`
+for Windows Position and check Open on Application Start. Use `MyEditor` for
Class Name Prefix.
++
+image::tutorials/selection-1_nb27_editor2.png[]
-Click btn:[Next].
-[start=3]
-1. Set the class name to "MyEditor", and click:[Finish] to complete the wizard.
+3. When the form editor opens, add two Text Fields (javax.swing.JTextField),
one above the other.
++
+image::tutorials/selection-1_nb27_editor4.png[]
++
+In the property sheet, set both text fields' "editable" property to `false`.
-You should see `MyEditor.java` open in with the Design view (form editor) open:
-
-image::tutorials/selection-1_editor3.png[]
-
-[start=4]
-1. When the form editor opens, drop two Text Fields (javax.swing.JTextField)
on the form, one above the other.
-
-image::tutorials/selection-1_editor4.png[]
-
-On the property sheet, set the "editable" property (checkbox) to `false` for
both text fields.
-
-[start=5]
-1. Click the Source button in the editor toolbar to switch to the code editor.
-
-[start=6]
-1. Change the signature of `MyEditor` to extends `TopComponent` instead of
`javax.swing.JPanel` and annotate the class to specify the location of the
window and the menu item for opening it:
+4. We want to allow the user to open more than one window. Click the Source
tab to switch to the code editorand delete
Review Comment:
editorand -> editor and
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -503,146 +503,160 @@ import org.openide.util.NbBundle;
import org.openide.util.lookup.Lookups;
import org.openide.windows.TopComponent;
----
-
-The line `associateLookup(Lookups.singleton(obj));` will create a `Lookup`
that contains only one object - the new instance of `Event` - and assign that
`Lookup` to be what is returned by `MyEditor.getLookup()`. While this is an
artificial example, you can imagine how `Event` might represent a file, an
entity in a database, or anything else you might want to edit or view. Probably
you can also imagine one component that allows you to select or edit multiple
unique instances of `Event`, which will be the subject of the next tutorial.
-
-To make your editor component at least somewhat interesting (though it doesn't
actually edit anything), you set the text fields' values to values from the
`Event`, so you have something to display.
++
+The line `associateLookup(Lookups.singleton(obj));` creates a `Lookup`
containing one object - the new `Event` instance.
+This becomes what `MyEditor.getLookup()` returns. While this is a simple
example, you can imagine `Event` representing a
+file, database entity, or anything else you want to edit or view. You could
also have a component that lets you select
+or edit multiple `Event` instances, which is covered in the next tutorial.
++
+To make the editor component interesting (though it doesn't actually edit
anything), you set the text fields to display
+values from the `Event`.
== Running the Code
-Now you're ready to run the tutorial. Simply right click `EventManager`, the
application which contains your three modules, and choose Run from the popup
menu. When the IDE opens, simply choose Window > Open Editor to invoke your
action. Do this a couple of times, so that there are several of your editor
components open. Your singleton `MyViewer` window should also be open. Notice
how the `MyViewer` window's contents change as you click different tabs, as
shown here:
-
-image::tutorials/selection-1_result1.png[]
+Now you're ready to run the tutorial. Right click `EventManager` and choose
Run. When the IDE opens, choose
+Window > Open Editor to invoke your action. Do this a few times to open
several editor components. Your `MyViewer`
+window should also be open. Notice how the `MyViewer` window content changes
as you click different tabs:
-If you click in the Viewer window, or close all of the editor windows, note
that the text changes to "[no selection]", as shown below:
+image::tutorials/selection-1_nb27_result1.png[]
-image::tutorials/selection-1_result2.png[]
+If you click in the Viewer window or close all editor windows, the text
changes to "[no selection]".
-NOTE: If you do not see the `MyViewer` window, you probably did not check the
checkbox in the wizard to open it on system start - simply go to the Window
menu and choose MyViewer to display it.
+NOTE: If you don't see the `MyViewer` window, you probably didn't check the
"open on system start" checkbox in the
+wizard. Go to the Window menu and choose MyViewer to display it.
== So, What's the Point?
-So the key point of this tutorial is the way the code is split into three
modules: the My Viewer module knows nothing about the My Editor module, and
either one can run by itself. They only share a common dependency on My API.
That means two things: 1. My Viewer and My Editor can be developed and shipped
independently, and 2. Any module that wants to provide a different sort of
editor than My Editor can do so, and the viewer component will work perfectly
with it, as long as the replacement editor offers an instance of `Event` from
its Lookup.
-
-To really picture the value of this, imagine `Event` were something much more
complex; imagine that `MyEditor` is an image editor, and ` Event` represents an
image being edited. The thing that's powerful here is that you could replace
`MyEditor` with, say, an SVG vector-based editor, and the viewer component
(presumably showing attributes of the currently edited image) will work
transparently with that new editor. It is this model of doing things that is
the reason you can add new tools into the NetBeans IDE that work against Java
files, and they will work in different versions of NetBeans, and that you can
have an alternate editor (such as the form editor) for Java files and all the
components and actions that work against Java files still work when the form
editor is used.
+The key point is how the code is split into three modules: My Viewer knows
nothing about My Editor, and either can run
+independently. They only share a dependency on My API. This means:
-This is very much the way NetBeans works with Java and other source files-in
their case, the thing that is available from the editor's Lookup is a `
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`, and components like
Navigator and the Property Sheet are simply watching what object is being made
available by the focused `TopComponent`.
+1. My Viewer and My Editor can be developed and shipped independently
+2. Any module can provide a different editor and the viewer will work with it,
as long as the new editor offers an
+`Event` from its Lookup
-Another valuable thing about this approach is that often people are migrating
existing applications to the NetBeans Platform. The object that is part of the
data model, in that case, is probably existing, working code that should not be
changed in order to integrate it into NetBeans. By keeping the data model's API
in a separate module, the NetBeans integration can be kept separate from the
core business logic.
+To understand the value, imagine `Event` is something complex - say `MyEditor`
is an image editor and `Event` represents
+an image being edited. You could replace `MyEditor` with an SVG vector editor,
and the viewer (showing image attributes)
+would work transparently with the new editor. This is why you can add new
tools to NetBeans IDE that work with Java
+files - they work across different NetBeans versions, and alternative editors
(like the form editor) still work with all
+components and actions that work with Java files.
Review Comment:
`and alternative editors (like the form editor) still work with all`
->
`and alternative editors (like the form editor) will continue to work with
all`
the original tutorial section was a bit rough, but this is probably what it
was trying to say?
`This is why you can add new tools to NetBeans IDE that work with Java`
and
`components and actions that work with Java files.`
replace `work` with `interact`
to not use work 4x in the same sentence
##########
modules/ROOT/pages/tutorials/nbm-selection-1.adoc:
##########
@@ -503,146 +503,160 @@ import org.openide.util.NbBundle;
import org.openide.util.lookup.Lookups;
import org.openide.windows.TopComponent;
----
-
-The line `associateLookup(Lookups.singleton(obj));` will create a `Lookup`
that contains only one object - the new instance of `Event` - and assign that
`Lookup` to be what is returned by `MyEditor.getLookup()`. While this is an
artificial example, you can imagine how `Event` might represent a file, an
entity in a database, or anything else you might want to edit or view. Probably
you can also imagine one component that allows you to select or edit multiple
unique instances of `Event`, which will be the subject of the next tutorial.
-
-To make your editor component at least somewhat interesting (though it doesn't
actually edit anything), you set the text fields' values to values from the
`Event`, so you have something to display.
++
+The line `associateLookup(Lookups.singleton(obj));` creates a `Lookup`
containing one object - the new `Event` instance.
+This becomes what `MyEditor.getLookup()` returns. While this is a simple
example, you can imagine `Event` representing a
+file, database entity, or anything else you want to edit or view. You could
also have a component that lets you select
+or edit multiple `Event` instances, which is covered in the next tutorial.
++
+To make the editor component interesting (though it doesn't actually edit
anything), you set the text fields to display
+values from the `Event`.
== Running the Code
-Now you're ready to run the tutorial. Simply right click `EventManager`, the
application which contains your three modules, and choose Run from the popup
menu. When the IDE opens, simply choose Window > Open Editor to invoke your
action. Do this a couple of times, so that there are several of your editor
components open. Your singleton `MyViewer` window should also be open. Notice
how the `MyViewer` window's contents change as you click different tabs, as
shown here:
-
-image::tutorials/selection-1_result1.png[]
+Now you're ready to run the tutorial. Right click `EventManager` and choose
Run. When the IDE opens, choose
+Window > Open Editor to invoke your action. Do this a few times to open
several editor components. Your `MyViewer`
+window should also be open. Notice how the `MyViewer` window content changes
as you click different tabs:
-If you click in the Viewer window, or close all of the editor windows, note
that the text changes to "[no selection]", as shown below:
+image::tutorials/selection-1_nb27_result1.png[]
-image::tutorials/selection-1_result2.png[]
+If you click in the Viewer window or close all editor windows, the text
changes to "[no selection]".
-NOTE: If you do not see the `MyViewer` window, you probably did not check the
checkbox in the wizard to open it on system start - simply go to the Window
menu and choose MyViewer to display it.
+NOTE: If you don't see the `MyViewer` window, you probably didn't check the
"open on system start" checkbox in the
+wizard. Go to the Window menu and choose MyViewer to display it.
== So, What's the Point?
-So the key point of this tutorial is the way the code is split into three
modules: the My Viewer module knows nothing about the My Editor module, and
either one can run by itself. They only share a common dependency on My API.
That means two things: 1. My Viewer and My Editor can be developed and shipped
independently, and 2. Any module that wants to provide a different sort of
editor than My Editor can do so, and the viewer component will work perfectly
with it, as long as the replacement editor offers an instance of `Event` from
its Lookup.
-
-To really picture the value of this, imagine `Event` were something much more
complex; imagine that `MyEditor` is an image editor, and ` Event` represents an
image being edited. The thing that's powerful here is that you could replace
`MyEditor` with, say, an SVG vector-based editor, and the viewer component
(presumably showing attributes of the currently edited image) will work
transparently with that new editor. It is this model of doing things that is
the reason you can add new tools into the NetBeans IDE that work against Java
files, and they will work in different versions of NetBeans, and that you can
have an alternate editor (such as the form editor) for Java files and all the
components and actions that work against Java files still work when the form
editor is used.
+The key point is how the code is split into three modules: My Viewer knows
nothing about My Editor, and either can run
+independently. They only share a dependency on My API. This means:
-This is very much the way NetBeans works with Java and other source files-in
their case, the thing that is available from the editor's Lookup is a `
xref:wiki::wiki/DevFaqDataObject.adoc[DataObject]`, and components like
Navigator and the Property Sheet are simply watching what object is being made
available by the focused `TopComponent`.
+1. My Viewer and My Editor can be developed and shipped independently
+2. Any module can provide a different editor and the viewer will work with it,
as long as the new editor offers an
+`Event` from its Lookup
-Another valuable thing about this approach is that often people are migrating
existing applications to the NetBeans Platform. The object that is part of the
data model, in that case, is probably existing, working code that should not be
changed in order to integrate it into NetBeans. By keeping the data model's API
in a separate module, the NetBeans integration can be kept separate from the
core business logic.
+To understand the value, imagine `Event` is something complex - say `MyEditor`
is an image editor and `Event` represents
+an image being edited. You could replace `MyEditor` with an SVG vector editor,
and the viewer (showing image attributes)
+would work transparently with the new editor. This is why you can add new
tools to NetBeans IDE that work with Java
+files - they work across different NetBeans versions, and alternative editors
(like the form editor) still work with all
+components and actions that work with Java files.
+This is how NetBeans IDE works with Java and other source files. The thing
available from the editor's Lookup is
+a xref:wiki::wiki/DevFaqDataObject.adoc[DataObject], and components like
Navigator and Property Sheet watch what object
+the focused `TopComponent` provides.
-== Changing Selected Objects on the Fly
-
-To make it really evident how powerful this approach can be, you'll take one
more step, and add a button to your editor component that lets it replace the
`Event` it has with a new one on the fly.
+This approach is also valuable when migrating existing applications to the
NetBeans Platform. The data model object is
+probably existing, working code that shouldn't change for NetBeans
integration. By keeping the data model API in a
+separate module, NetBeans integration stays separate from core business logic.
-[start=1]
-1. Open `MyEditor` in the form editor (click the Design toolbar button in the
editor toolbar), and drag a `Button` (javax.swing.JButton) to it.
-
-[start=2]
-1. Set the `text` property of the JButton to "Replace".
+== Changing Selected Objects on the Fly
-image::tutorials/selection-1_replace1.png[]
+To show how powerful this approach is, you'll add a button to your editor that
replaces the `Event` with a new one
+on the fly.
-[start=3]
-1. Right click the `JButton` and choose Events > Action > actionPerformed.
-image::tutorials/selection-1_replace2.png[]
+1. Open `MyEditor` in the form editor (click the Design button) and drag a
`Button` (javax.swing.JButton) to it.
-This will cause the code editor to open with the cursor in an event handler
method. Make that method call `updateContent()`.
+2. Set the button's `text` property to "Replace".
+3. Right click the `JButton` and choose Events > Action > actionPerformed.
++
+This opens the code editor with the cursor in an event handler method. Make
the method call `updateContent()`:
++
[source,java]
----
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
updateContent();
}
----
-
-Implement the missing method:
-
++
+Add the missing method:
++
[source,java]
----
- private void updateContent() {
- Event obj = new Event();
- jTextField1.setText ("Event #" + obj.getIndex());
- jTextField2.setText ("Created: " + obj.getDate());
- setDisplayName ("MyEditor " + obj.getIndex());
- content.set(Collections.singleton (obj), null);
- }
+private void updateContent() {
+ Event obj = new Event();
+ jTextField1.setText ("Event #" + obj.getIndex());
+ jTextField2.setText ("Created: " + obj.getDate());
+ setDisplayName ("MyEditor " + obj.getIndex());
+ content.set(Collections.singleton (obj), null);
+}
Review Comment:
we could also remove the space before the `(` to align it with the default
formatting settings
```
Event obj = new Event();
jTextField1.setText("Event #" + obj.getIndex());
jTextField2.setText("Created: " + obj.getDate());
setDisplayName("MyEditor " + obj.getIndex());
content.set(Collections.singleton(obj), null);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
