Showing posts with label NetBeans. Show all posts
Showing posts with label NetBeans. Show all posts

3.8.10

NetBeans Platform Porting Tutorial

This tutorial demonstrates how to port a simple Swing application to the NetBeans Platform. Though the scenario below is simple, the basic concepts of "porting" an application to the NetBeans Platform will become clear. In the end, some general principles will be identified, based on the steps taken in the tutorial. Hopefully, they will be useful to you when porting your own Swing applications to the NetBeans Platform.

Contents

Content on this page applies to NetBeans IDE 6.5, 6.7, 6.8

To follow this tutorial, you need the software and resources listed in the following table.

Software or Resource
Version Required

NetBeans IDE
version 6.9 or above

Java Developer Kit (JDK)
version 6

Introduction to Porting

Before beginning this procedure, it makes sense to ask why one would want to do so in the first place. A typical Swing application consists of a domain-specific layer on top of a general framework. The general framework normally provides features dealing with an application's infrastructure, such as an application's menu bar, windowing system (also known as "docking framework"), and lifecycle management. Typically this framework is very generic and is (or could be) reused by many applications within the same organization. The NetBeans Platform exists specifically to cater to these infrastructural concerns. You do not need to create these on your own for your own Swing applications. You can simply move the useful domain-specific parts of your application to the NetBeans Platform and then, from that point onwards, the NetBeans Platform will be the new underlying 'plumbing' layer of your application. You can then focus on the more interesting parts of your application, specifically, the domain-specific parts. This will speed up your development process and give you a consistent basis for all your applications.

In this tutorial, we will begin with the Anagram Game, which is a standard Swing application sample that is distributed with NetBeans IDE. We will, step by step, move it to the NetBeans Platform and gradually see the advantages of doing so.

Getting the Anagram Game

We begin by getting the Anagram Game, which is one of the IDE's standard Java samples, from the New Project wizard. Then we run it and analyze its parts.

  1. Choose File > New Project (Ctrl-Shift-N). Under Categories, select Samples > Java. Under Projects, select Anagram Game. Click Next and Finish.

    You should now see the Anagram Game application outlined in the Projects window, as shown here:

    The application contains the following classes:

    • WordLibrary.java. Provides an abstract class, with abstract methods like getWord(int idx),getScrambledWord(int idx), and isCorrect(int idx, String userGuess).
    • StaticWordLibrary.java. Extends WordLibrary.java, providing a list of scrambled words, as well as their unscrambled equivalents, together with the getters and setters for accessing them and for evaluating them.
    • Anagrams.java. Provides the main user interface of the application, principally consisting of a JFrame with a JPanelcontaining labels and text fields. Also included is a menu bar containing a File menu, with the menu items 'About' and 'Exit'.
    • About.java. Provides the About box, accessed from the File menu.
  2. Run the application and you should see the following:

  3. When you specify the correctly unscrambled word, you will see this:

Before porting this application to the NetBeans Platform, we need to think about the stages in which we want to port our application. In other words, you do not need to port everything at once. And there are different levels to which you can integrate your application, from a mostly superfical level to a level that aligns your application completely with the paradigms and purposes of the NetBeans Platform. The next section will show the levels of compliance your application can have with the NetBeans Platform.

Levels of Compliance

Converting an application to be fit for a framework such as the NetBeans Platform can be done on various levels. The integration can be shallow and use just a few integration points or it can be deeper, tightly following the paradigms of the NetBeans Platform.

The stages can be described as follows:

Level 0: Launchable

One or more of the following can be done to make your application launchable with as few changes as possible:

  • Enhance your manifest with NetBeans key/value pairs so that your JAR is recognized as an OSGi bundle or as a NetBeans module.
  • Set dependencies between modules. In the manifest, with instances of plain Class-Path you can set dependencies between modules.
  • Register a menu item in the declarative layer file (layer.xml) of your module, to invoke your original application. This file can be created automatically when you create a new module project in NetBeans IDE, as you will see later.

In this tutorial, we will do all of the above. We will enhance the manifest, which the module project wizard will do for us. We will create a menu item that will invoke our application. To do so, we will move our application's classes into a module source structure. Then we will use the New Action wizard to create a new menu item, which will automatically be registered for us, and a dependency will be set on the UI Utilities API, which we will need to implement the Action. From that action, we will invoke our application.

Level 1: Integrated

Here are some pointers for integrating the application more tightly with the NetBeans Platform:

  • Integrate visually to get the benefits of the NetBeans Window System, which is its docking framework.
  • Use NetBeans Window System API and the Dialog APIs, primarily the TopComponent class and the DialogDisplayer class.
  • Change initialization code of your application, use the ModuleInstall class or declarative registrations, through the layer file or the META-INF/services folder.

In this tutorial, we will move the relevant parts of the JPanel from the JFrame to a new TopComponent. The TopComponentclass creates a window on the NetBeans Platform, which in our case will show our JPanel.

Level 2: Use Case Support

This level of compliance with the NetBeans Platform is concerned with one or more of the following activities:

  • Bind your application to other modules by inspecting existing functionality and trying to use it.
  • Simplify the workflow to fit into the NetBeans Platform paradigms.
  • Listen to the global selection to discover what other modules are doing and update your state accordingly.

In this tutorial, we will listen for the existence of EditorCookies. A cookie is a capability. With a Java interface, your object's capabilities are fixed at compile time, while NetBeans Platform cookies allow your object to behave dynamically because your object can expose capabilities, or not, based on its state. An EditorCookie defines an editor, with interfaces for common activities such as opening a document, closing the editor, background loading of files, document saving, and modification notifications. We will listen for the existence of such a cookie and then we will pass the content of the editor to theTopComponent, in the form of words. By doing this, we are doing what the first item above outlines, i.e., inspecting existing functionality and reusing it within the context of our ported application. This is a modest level of integration. However, it pays off because you are reusing functionality provided by the NetBeans Platform.

Level 3: Aligned

In this final stage of your porting activity, you are concerned with the following thoughts, first and foremost:

  • Become a good citizen of the NetBeans Platform, by exposing your own state to other modules so that they know what you are doing.
  • Eliminate duplicated functionality, by reusing the Navigator, Favorites window, Task List, Progress API, etc., instead of creating or maintaining your own.
  • Cooperate with other modules and adapt your application to the NetBeans Platform way of doing things.

Towards the end of this tutorial, we will adopt this level of compliance by letting our TopComponent expose a SaveCookiewhen changes are made to the "Guessed Word" text field. By doing this, we will enable the Save menu item under the Tools menu. This kind of integration brings the full benefits of the NetBeans Platform, however it also requires some effort to attain.

Creating the NetBeans Platform Application

First, let's create the basis of our application. We use a wizard to do so. This is the typical first practical step of creating a new application on top of the NetBeans Platform application.

  1. Choose File > New Project (Ctrl-Shift-N). Under Categories, select NetBeans Modules. Under Projects, select NetBeans Platform Application, as shown below:

    Click Next.

  2. Name the application AnagramApplication, as shown below:

    Click Finish

    You now have a NetBeans Platform application. You can run it and you will see an empty main window, with a menu bar and a tool bar. Look under some of the menus, click a few toolbar buttons, and explore the basis of your new application.

    Next, we create our first custom module. We will name it AnagramUI because, in the end, it will only contain the user interface (UI) of the application. In a subsequent tutorial, we will add additional modules, which will provide an API and an implementation of the business logic. But, for the moment, we will port everything into the module that will ultimately provide only the UI of the application.

  3. Choose File > New Project (Ctrl-Shift-N) again. Under Categories, select NetBeans Modules. Under Projects, select Module, as shown below:

    Click Next.

  4. Type AnagramGameUI in Project Name and choose somewhere to store the module, as shown below:

    Click Next.

  5. Type a unique name in the Code Name Base field, which provides the unique identifier for your module. It could be anything, but here it is org.anagram.ui.

    Note: Optionally, check "Generate XML Layer". If you do not select it, that's fine, because later in this tutorial you will be shown how to create it manually and you will also learn what it is used for.

  6. Click Finish.

    Below the Anagram Game sample, you should now see the source structure of your new module, as shown here:

Above, we can see that we now have the original application, together with the module to which it will be ported. In the next sections, we will begin porting the application to the module, using the porting levels described earlier.

Porting Level 0: Launchable

At this stage, we simply want to be able to launch our application from a module. To do that we will create a menu item that invokes the application. We begin by copying the application's sources into the module source structure.

  1. Copy the two packages from the Anagram Game into the module. Below, the new packages and classes in the module are highlighted:

  2. In the org.anagram.ui package, create a new Java class named OpenAnagramGameAction, implementing the standard JDK ActionListener as follows:

    import com.toy.anagrams.ui.Anagrams;
    import java.awt.event.ActionEvent;
    import java.awt.event.ActionListener;

    public class OpenAnagramGameAction implements ActionListener {

    @Override
    public void actionPerformed(ActionEvent e) {
    new Anagrams().setVisible(true);
    }

    }

    When the user invokes the OpenAnagramGameAction, the JFrame from the Anagram Game will open.



  3. Next, we need to register the new OpenAnagramGameAction in the NetBeans central registry, which is also known as the "System FileSystem".

    If you do not have a file named layer.xml yet, create one in the org.anagram.ui package, with this content:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE filesystem PUBLIC "-//NetBeans//DTD Filesystem 1.2//EN" "http://www.netbeans.org/dtds/filesystem-1_2.dtd">
    <filesystem>

    <folder name="Actions">
    <folder name="Window">
    <file name="org-anagram-ui-OpenAnagramGameAction.instance">
    <attr name="delegate" newvalue="org.anagram.ui.OpenAnagramGameAction"/>
    <attr name="instanceCreate" methodvalue="org.openide.awt.Actions.alwaysEnabled"/>
    <attr name="displayName" bundlevalue="org.anagram.ui.Bundle#CTL_OpenAnagramGameAction"/>
    </file>
    </folder>
    </folder>
    <folder name="Menu">
    <folder name="Window">
    <file name="OpenLibraryViewerWindowAction.shadow">
    <attr name="originalFile" stringvalue="Actions/Window/org-anagram-ui-OpenAnagramGameAction.instance"/>
    </file>
    </folder>
    </folder>

    </filesystem>

    Each module in your application can have, at most, one layer.xml file. The file is used to register contributions to the NetBeans Platform application. For example, new windows and new Actions are registered here, in folders specifically dedicated to the contribution in question. Above, you can see we are dealing with the "Actions" folder and the "Menu" folder. Some notes on the elements and attributes above:



    • Above, in the "delegate" attribute, you have registered the OpenAnagramGameAction class. In the "instanceCreate" attribute, you have specified that the NetBeans Platform method org.openide.awt.Actions.alwaysEnabled will be called when the OpenAnagramGameAction is invoked. This is a NetBeans Platform method that creates an Action that is always enabled, regardless of the context of the application. Since you want the Anagram Game to be able to be started at any time, it makes sense for the Action to always be enabled.



    • The "displayName" attribute above points to a key in the Bundle.properties file, which is the central file for storing all the localizable strings in the module.



    • While the "Actions" folder registers the Action, the "Menu" folder specifies where the Action will be displayed. Above, you can see that the Action will be displayed in the Window menu.



  4. In the Bundle.properties file, add the following key/value pair, based on the "displayName" attribute above:

    CTL_OpenAnagramGameAction=Open Anagram Game


  5. In the Module Manifest, which you can find in the Important Files node in the module, and which is manifest.mf on disk, register the layer.xml file as follows:

    OpenIDE-Module-Layer: org/anagram/ui/layer.xml


  6. In the Projects window, right-click the AnagramApplication project node and choose Run. The application starts up, installing all the modules provided by the application, which includes our custom module.


  7. Under the Window menu, you should find the menu item "Open Anagram Game". Choose it and your application appears.

The application is displayed, but note that it is not well integrated with the NetBeans Platform. For example, it is not modal and it is impossible to close the JFrame, unless you close the entire application. The latter is because the entire application now manages the lifecycle of the JFrame. In the next section, we will integrate the Anagram Game more tightly with the NetBeans Platform.

Note: In the section above, you manually created and registered a layer.xml file and you manually created anActionListener and you manually registered the ActionListener in the layer.xml file. Now that you know how and why and where these activities occur, you can automate the process. Whenever you create a new module, select the "Generate XML Layer" checkbox, which will let the IDE automatically create the layer.xml file and the IDE will also register it in themanifest.mf file for you. In addition, you can automate the creation and registration of Actions by using the "New Action" wizard, which is available in the New File dialog (Ctrl-N). Also, whenever you use a wizard that registers something in thelayer.xml file, such as the New Action wizard does, and the layer.xml file does not exist, the layer.xml file will automatically be created for you.

Porting Level 1: Integration


In this section, we integrate the application more tightly by creating a new window, so that we have a user interface, that is., a window, to which we can move those contents of the JFrame that are useful to our new application.



  1. Right-click the org.anagram.ui package in the Projects window and then choose New > Other. Under Categories, select Module Development. Under File Types, select Window.


    Click Next.



  2. Choose the position where you would like the window to appear. For purposes of this tutorial choose "editor", which will place the Anagram Game in the main part of the application:


    Optionally, specify whether the window should open automatically when the application starts up.

    Click Next.



  3. Type Anagram in Class Name Prefix and select org.anagram.ui in Package, as shown here:


    Above, notice that the IDE shows the files it will create and modify.



  4. Click Finish.

    Now you have a set of new Java and XML source files, as shown here:



  5. Open the Anagrams class in the com.toy.anagrams.ui package. Also open the AnagramTopComponent, which was created in the previous step. When you click the mouse in the Anagram class, notice that the labels and text fields are in a Swing container, in this case a JPanel, as shown here:


    Tip: If the Swing components were not within a container, you could select them all with the mouse, then right-click and choose "Enclose In", to let the IDE create a container within which all the selected components would be enclosed.



  6. Right-click the JPanel and copy it. Paste it in the TopComponent and you should see the old user interface in your newTopComponent class:



  7. You have now ported the user interface of the Anagram Game. A few variables need still to be moved from the Anagramsclass to the new AnagramTopComponent class. Declare these two, which are in the Anagrams class, at the top of your newAnagramTopComponent class.

    private int wordIdx = 0;
    private WordLibrary wordLibrary;

    Next, look in the constructor of the Anagrams class. The first line in the constructor is as follows:

    wordLibrary = WordLibrary.getDefault();

    Copy that statement. Paste it into the TopComponent class, making it the new first statement in the constructor of theTopComponent class.



  8. Next, open the Bundle.properties file. The content should be something similar to this:

    CTL_AnagramAction=Anagram
    CTL_AnagramTopComponent=Anagram Window
    HINT_AnagramTopComponent=This is a Anagram window
    OpenIDE-Module-Name=AnagramGameUI
    CTL_OpenAnagramGameAction=Open Anagram Game
    AnagramTopComponent.feedbackLabel.text=\
    AnagramTopComponent.guessLabel.text=Your Guess:
    AnagramTopComponent.scrambledLabel.text=Scrambled Word:
    AnagramTopComponent.nextTrial.toolTipText=Fetch a new word.
    AnagramTopComponent.nextTrial.text=New Word
    AnagramTopComponent.guessButton.toolTipText=Guess the scrambled word.
    AnagramTopComponent.guessButton.text=Guess

    Notice line 6 above. The IDE erroneously created a backslash instead of a space in the key/value pair in line 6 above. If you have a line where the value is set to be a backslash, simply delete the backslash.

    If you do not delete the backslash, when you run the application, in the next step, you will see error messages such as these:

    --java.util.MissingResourceException: Can't find resource for bundle
    org.openide.util.NbBundle$PBundle, key AnagramTopComponent.guessLabel.text

    --java.lang.AssertionError: Component cannot be created for {component=null,
    displayName=Anagram, instanceCreate=AlwaysEnabledAction[Anagram]}

    If you see the above error messages, open the Bundle.properties file and remove the erroneously generated backslash. This is a known bug.



  9. Run the application again. When the application starts up, you should now see the Anagram Game window, which you defined in this section. You will also find a new menu item that opens the window, under the Window menu. Also notice that the game works as before. You need to click the "New Word" button once, to have the module call up a new word, and then you can use it as before:



  10. As a final step in this section, you can simply delete the com.toy.anagrams.ui package. That package contains the two UI classes from the original Anagram Game. You do not need either of these two classes anymore. Simply delete the package that contains them, since you have ported everything of interest to the NetBeans Platform.

    Then also delete the OpenAnagramGameAction class, as well as the registration entries you manually added to thelayer.xml file earlier in this tutorial. Be careful when you delete these entries, since others have been added to thelayer.xml file in the meantime and you do not want to delete entries that do not relate to this specific Action that you are deleting!


Porting Level 2: Use Case Support


In this section, we are concerned with listening to the global selection and making use of data we find there. The global selection is the registry for global singletons and instances of objects which have been registered in the system by modules. Here we query the lookup for EditorCookies and make use of the EditorCookie's document to fill the string array that defines the scrambled words displayed in the TopComponent.

A cookie is a capability. With a Java interface, your object's capabilities are fixed at compile time, while NetBeans Platform cookies allow your object to behave dynamically because your object can expose capabilities, or not, based on its state. AnEditorCookie defines an editor, with interfaces for common activities such as opening a document, closing the editor, background loading of files, document saving, and modification notifications. We will listen for the existence of such a cookie and then we will pass the content of the editor to the TopComponent, in the form of words. By doing this, we are inspecting existing functionality and reusing it within the context of our ported application. This is a modest level of integration. However, it pays off because you are reusing functionality provided by the NetBeans Platform.


  1. We begin by tweaking the StaticWordLibrary class. We do this so that we can set its list of words externally. The sample provides a hardcoded list, but we want to be able to set that list ourselves, via an external action. Therefore, add this method to StaticWordLibrary:
    public static void setScrambledWordList(String[] inScrambledWordList) {
    SCRAMBLED_WORD_LIST = inScrambledWordList;
    }

    Importantly, change the class signature of StaticWordLibrary to public class and remove the final from the signature of SCRAMBLED_WORD_LIST

    Next, we will create an action that will obtain the content of a Manifest file, break the content down into words, and fill theSCRAMBLED_WORD_LIST string array with these words.


  2. Right-click the module, choose Properties, and then open the Libraries tab in the Project Properties dialog. Click "Add Dependency" and then set dependencies on the Text API and the Nodes API.
  3. In the Source Editor, create a Java class named SetScrambledAnagramsAction and define it as follows:
    public final class SetScrambledAnagramsAction implements ActionListener {

    private final EditorCookie context;

    public SetScrambledAnagramsAction(EditorCookie context) {
    this.context = context;
    }

    @Override
    public void actionPerformed(ActionEvent ev) {
    try {
    //Get the EditorCookie's document:
    StyledDocument doc = context.getDocument();
    //Get the complete textual content:
    String all = doc.getText(0, doc.getLength());
    //Make words from the content:
    String[] tokens = all.split(" ");
    //Pass the words to the WordLibrary class:
    StaticWordLibrary.setScrambledWordList(tokens);
    //Open the TopComponent:
    TopComponent win = AnagramTopComponent.findInstance();
    win.open();
    win.requestActive();
    } catch (BadLocationException ex) {
    Exceptions.printStackTrace(ex);
    }
    }

    }


  4. Register the Action above in the layer file. Unlike the previous Action, the Action above should not always be enabled. It should be available for Manifest files only, since that is the file type we happen to be interested in. Furthermore, the Action should only be enabled if an EditorCookie is present. The result of these requirements is a registration with this content:

    <folder name="Actions">
    <folder name="Window">
    <file name="org-anagram-ui-SetScrambledAnagramsAction.instance">
    <attr name="delegate" methodvalue="org.openide.awt.Actions.inject"/>
    <attr name="displayName" bundlevalue="org.anagram.ui.Bundle#CTL_SetScrambledAnagramsAction"/>
    <attr name="injectable" stringvalue="org.anagram.ui.SetScrambledAnagramsAction"/>
    <attr name="instanceCreate" methodvalue="org.openide.awt.Actions.context"/>
    <attr name="noIconInMenu" boolvalue="false"/>
    <attr name="selectionType" stringvalue="EXACTLY_ONE"/>
    <attr name="type" stringvalue="org.openide.cookies.EditorCookie"/>
    </file>
    </folder>
    </folder>
    <folder name="Editors">
    <folder name="text">
    <folder name="x-manifest">
    <folder name="Popup">
    <file name="org-anagram-ui-SetScrambledAnagramsAction.shadow">
    <attr name="originalFile" stringvalue="Actions/Window/org-anagram-ui-SetScrambledAnagramsAction.instance"/>
    <attr name="position" intvalue="900"/>
    </file>
    </folder>
    </folder>
    </folder>
    </folder>

    Many of the attributes above you have used previously. For example, the "displayName" attribute points to a key in theBundle.properties file. This key does not exist yet. Create it now, in the Bundle.properties file, as follows:

    CTL_SetScrambledAnagramsAction=Set Scrambled Words

    The instanceCreate attribute specifies that the org.openide.awt.Actions.context method handles the Action.

    Note: Above, you manually created an Action class and registered it in the layer.xml file. Now that you know how to do this, feel free to use the New Action wizard (in the New File dialog, Ctrl-N) instead to create context-sensitive Actions from now onwards.



  5. As discussed above, when we run the application we want to be able to right-click within a Manifest file, choose a menu item, and invoke our Action. Right now, however, the NetBeans Platform is unable to distinguish Manifest files from any other file. Therefore, we need to enable Manifest support in our application.

    For demonstration purposes, we will enable ALL the modules in the NetBeans Platform, as well as those provided by NetBeans IDE. As a result, when we run the application, a new instance of NetBeans IDE will start up, together with our custom module.

    To achieve the above, expand the Important Files node, then open the NetBeans Platform Config file, which on disk is namedplatform.properties. Notice that many modules have been disabled. You can enable them via the Project Properties dialog of the NetBeans Platform application. Since we are simply going to enable ALL of them, we need only change the content of the platform.properties file to the following:

    cluster.path=\
    ${nbplatform.active.dir}/apisupport:\
    ${nbplatform.active.dir}/harness:\
    ${nbplatform.active.dir}/ide:\
    ${nbplatform.active.dir}/java:\
    ${nbplatform.active.dir}/nb:\
    ${nbplatform.active.dir}/platform:\
    ${nbplatform.active.dir}/profiler:\
    ${nbplatform.active.dir}/websvccommon
    disabled.modules=
    nbplatform.active=default

    In the next step, when we run the application, all the groups of modules (called "clusters") will be enabled, nothing will be excluded, and you will see NetBeans IDE started up.



  6. Run the application. Go to the Window menu and choose Favorites. In the Favorites window, browse to a Manifest file. Open the file. Inside the file, i.e., in the Manifest Editor, right-click, and invoke the Set Scrambled Words action via the menu item.


    The AnagramTopComponent is displayed and, when you click the Next Word button, you will see that the scrambled words all come from the selected Manifest file.


The result of this exercise is that you now see the content of the Manifest file in the Scrambled Word text field. Of course, these words are not really scrambled and you cannot really unscramble them. However, your module is making use of the content of a file that is supported by a different set of modules altogether, that is, the Manifest support modules, as well as related editor modules.

Optionally, before continuing, you can now remove all the groups of modules (known as "clusters") provided by NetBeans IDE, which may not be relevant for your own application. To do so, right-click the AnagramApplication node in the Projects window, choose Properties, go to the Libraries tab, and uncheck all the checkboxes, except for harness and platform. Run the application again and you will see that all the project-related and editor-related features of the application have now been removed.

Porting Level 3: Aligned


In this section, we are concerned with becoming a "good citizen" of the NetBeans Platform. We are going to expose the state of the TopComponent to the other modules, so that we can cooperate with them.

As an example of this, we will modify the TopComponent to offer a SaveCookie, which gives the user a way to store the text typed in the text field. By offering the SaveCookie when changes are made in the text field, the Save button and the Save menu item under the File menu will become enabled. That is because the NetBeans Platform provides a context-sensitive Action calledSaveAction. The SaveAction becomes enabled whenever the capability of being saved, in other words, the SaveCookie, is available. In this case, we will make the SaveCookie available whenever the user types something in the guessedWord text field. Then the SaveAction will automatically become enabled.

When the user selects the enabled button or menu item, a dialog will be displayed and the button and menu item will become disabled, until the next time that a change is made to the text field.


  1. Begin by setting a dependency on the Dialogs API. Do this by right-clicking the project node in the Projects window, choosing Properties, and then using the Libraries tab to add the Dialogs API as a dependency of the module.
  2. Next, we define an implementation of the SaveCookie, somewhere within the AnagramTopComponent class:
    private class SaveCookieImpl implements SaveCookie {

    @Override
    public void save() throws IOException {

    Confirmation msg = new NotifyDescriptor.Confirmation("Do you want to save \""
    + guessedWord.getText() + "\"?", NotifyDescriptor.OK_CANCEL_OPTION,
    NotifyDescriptor.QUESTION_MESSAGE);

    Object result = DialogDisplayer.getDefault().notify(msg);

    //When user clicks "Yes", indicating they really want to save,
    //we need to disable the Save button and Save menu item,
    //so that it will only be usable when the next change is made
    //to the text field:
    if (NotifyDescriptor.YES_OPTION.equals(result)) {
    fire(false);
    //Implement your save functionality here.
    }

    }

    }

    We have not defined the fire method yet, so the related statement above will be underlined in red until we do so.



  3. In the constructor, call the as-yet-undefined fire method, passing in true this time, whenever a change is detected in theguessedWord text field:

    guessedWord.getDocument().addDocumentListener(new DocumentListener() {

    @Override
    public void insertUpdate(DocumentEvent arg0) {
    fire(true);
    }

    public void removeUpdate(DocumentEvent arg0) {
    fire(true);
    }

    public void changedUpdate(DocumentEvent arg0) {
    fire(true);
    }

    });


  4. Now we declare an InstanceContent at the top of the class. The InstanceContent class is a very powerful class in the NetBeans Platform, enabling you to update the Lookup on the fly, at runtime. We also declare the implementation of ourSaveCookie:

    InstanceContent ic;
    SaveCookieImpl impl;


  5. Next, at the end of the constructor, we instantiate the SaveCookie and the InstanceContent, while adding theInstanceContent to the Lookup of the AnagramTopComponent:

    impl = new SaveCookieImpl();

    ic = new InstanceContent();

    associateLookup(new AbstractLookup(ic));


  6. Now we can add the fire method, which dynamically adds and removes the SaveCookie from the InstanceContent:

    public void fire(boolean modified) {
    if (modified) {
    //If the text is modified,
    //we add the SaveCookie implementation
    //to the InstanceContent, which
    //is in the Lookup of the TopComponent:
    ic.add(impl);
    } else {
    //Otherwise, we remove the SaveCookie
    //from the InstanceContent:
    ic.remove(impl);
    }
    }

  7. By default, you have a Save menu item under the File menu, but no Save button in the toolbar. For testing purposes, that is, to simplify checking whether the SaveAction is enabled, you may want a Save button in the toolbar. For this purpose, add the following to the layer:
    <folder name="Toolbars">
    <folder name="File">
    <file name="org-openide-actions-SaveAction.shadow">
    <attr name="originalFile" stringvalue="Actions/System/org-openide-actions-SaveAction.instance"/>
    <attr name="position" intvalue="444"/>
    </file>
    </folder>
    </folder>


  8. Run the application again. Make a change in the "Guessed Word" text field and notice that the Save button and the Save menu item become enabled:


    Select either the button or the menu item, click the "OK" button in the dialog...


    ...and notice that the Save functionality is disabled afterwards.


Congratulations! Now that your application is making use of existing NetBeans Platform functionality, you have taken one further step in successfully aligning it with the NetBeans Platform. Other modules can be now be plugged into the NetBeans Platform to take advantage of, or even extend, features added by your application. Hence, not only can your application benefit from what the NetBeans Platform provides, but you can create features that other modules can use as well.

Porting Tips & Tricks


There are several next steps one can take at this point, aside from further aligning the application with the NetBeans Platform, as outlined above:


  • Attain a thorough understanding of what the NetBeans Platform provides. As you port your application, you will learn more and more about the various features that the NetBeans Platform makes available. A central problem is that the NetBeans Platform is quite large and attaining a thorough overview of all that it offers can be a lengthy process. A quick shortcut is to download and print out the Essential NetBeans Platform Refcard, which is a free DZone document that highlights all the NetBeans Platform benefits, features, APIs, and many tips and tricks in an easy to digest format.
  • Become aware of the differences between standard Swing applications and the NetBeans Platform. For the most part, the standard Swing approach to creating a user interface will continue to work for your NetBeans Platform application. However, the NetBeans Platform approach is better, easier, or both in some cases. One example is that of the NetBeans Dialogs API. The standard Swing approach, via, for example, the JOptionsPane, works OK, but using the NetBeans Dialogs API is easier, because it automatically centers your dialog in the application and allows you to dismiss it with the ESC key. Using the Dialogs API also lets you plug in a different DialogDisplayer, which can make it easier to customize or test your application.

    Below is a list of the principle differences between the typical Swing approach and that of the NetBeans Platform:


    • Loading of images
    • Loading of resource bundles and localized string
    • Assigning of mnemonics to labels and buttons
    • Showing dialogs

    For details on all of the above items, read this FAQ: Common calls that should be done slightly differently in NetBeans than standard Swing apps (loading images, localized strings, showing dialogs).

    In addition, note that, since the NetBeans Platform now handles the lifecycle of your module, since it is now part of the whole application, you can no longer use System.exit. Instead, you need to use LifecycleManager. To run code on start up, which should only be done when absolutely necessary, you need to use the NetBeans ModuleInstall class and, specifically, its restored method. A useful reference in this context is Porting a Java Swing Application to the NetBeans Platform, by Tom Wheeler, in Building A Complete NetBeans Platform Application.



  • Create a module project for each distinct part of your application. The NetBeans Platform provides a modular architecture out of the box. Break your application into one or more modules. Doing so requires some analysis of your original application and an assessment of which parts could best fit within a new module and how to communicate between them. Since the example in this tutorial was simple, we only needed one module. A next step might be to put the WordLibraryclass in a separate module and expose it as a public API. The StaticWordLibrary would be put into another module, providing an implementation of the WordLibrary API. Doing so would let other modules provide user interfaces on top of the API provided by the first module, without depending in any way on the implementations.

    As shown above, you need to put the modules in a module suite. Then set a dependency in the plugin module on the API module, using the Libraries panel in the plugin module's Project Properties dialog box. The size of each module, i.e., when one should create a new module or continue developing within an existing one, is a question of debate. Smaller is better, in general.


  • Always keep reevaluating what you really need to port. Look at the NetBeans Platform and decide where there is overlap with your own application. Where there is overlap, such as the menu bar and About box, decide what you want to do. Typically, you want to leverage as much as possible from the NetBeans Platform. Therefore, you would port as little as possible from your own application, while keeping as much of it as is useful to you.
  • Move distinct parts of your user interface to one or more TopComponents. On the NetBeans Platform, theTopComponent class provides the top level Swing container. In effect, it is a window. Move the user interface from your original application to one or more of these windows and discard your original JFrames.
  • Copy the Java classes that do not provide user interface elements. We simply copied the originalWordLibrary.java class. You can do the same with the model of your own Swing applications. You might need to tweak some code to smoothen the transition between the old Swing application and the new NetBeans Platform application, but (as in the case shown in this tutorial) this might not even be necessary.
  • Learn from others. Aside from joining the dev@platform.netbeans.org mailing list, also read the following two crucial articles:

  • Watch the Top 10 NetBeans APIs Screencast. The screencast series gives a good overview of the NetBeans Platform, with many useful code snippets and coding patterns.

http://platform.netbeans.org/tutorials/nbm-porting-basic.html

2.8.10

NetBeans Source Code Download

http://netbeans.org/downloads/zip.html

The Continuing March of ActionListener in the NetBeans Platform

One of the interesting enhancements to the NetBeans Platform in NetBeans Platform 6.5 was the fact that you can now use the standard JDK ActionListener class when creating 'aways enabled' menu items and toolbar buttons in your NetBeans Platform applications.

In the next release of the NetBeans Platform, i.e., after 6.7, this will go a step further. When you create 'conditionally enabled' actions, such as those that appear in the Java editor's contextual menu, you will be able to define your action like this:

import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import org.openide.cookies.EditorCookie;

public final class BSomeAction implements ActionListener {

private final EditorCookie context;

public BSomeAction(EditorCookie context) {
this.context = context;
}

public void actionPerformed(ActionEvent ev) {
// TODO use context
}

}

So, again, you're using a plain old ActionListener, with the context that you're working with (the editor) being the only foreign class in your code.

Assuming you want the action to be invoked from a menu item on a node in the explorer view, the layer entries for the above would be as follows:

    <folder name="Actions">
<folder name="Build">
<file name="org-demo-bla2-BSomeAction.instance">
<attr name="delegate" methodvalue="org.openide.awt.Actions.inject"/>
<attr name="displayName" bundlevalue="org.demo.bla2.Bundle#CTL_BSomeAction"/>
<attr name="injectable" stringvalue="org.demo.bla2.BSomeAction"/>
<attr name="instanceCreate" methodvalue="org.openide.awt.Actions.context"/>
<attr name="noIconInMenu" boolvalue="false"/>
<attr name="selectionType" stringvalue="EXACTLY_ONE"/>
<attr name="type" stringvalue="org.openide.cookies.EditorCookie"/>
</file>
</folder>
</folder>
<folder name="Loaders">
<folder name="text">
<folder name="x-java">
<folder name="Actions">
<file name="org-demo-bla2-BSomeAction.shadow">
<attr name="originalFile" stringvalue="Actions/Build/org-demo-bla2-BSomeAction.instance"/>
<attr name="position" intvalue="0"/>
</file>
</folder>
</folder>
</folder>
</folder>

If, on the other hand, the action class were to appear within the editor itself, the layer registration would be as follows:

   <folder name="Actions">
<folder name="Build">
<file name="org-demo-bla3-BSomeAction.instance">
<attr name="delegate" methodvalue="org.openide.awt.Actions.inject"/>
<attr name="displayName" bundlevalue="org.demo.bla3.Bundle#CTL_BSomeAction"/>
<attr name="injectable" stringvalue="org.demo.bla3.BSomeAction"/>
<attr name="instanceCreate" methodvalue="org.openide.awt.Actions.context"/>
<attr name="noIconInMenu" boolvalue="false"/>
<attr name="selectionType" stringvalue="EXACTLY_ONE"/>
<attr name="type" stringvalue="org.openide.cookies.EditorCookie"/>
</file>
</folder>
</folder>
<folder name="Editors">
<folder name="text">
<folder name="x-java">
<folder name="Popup">
<file name="org-demo-bla3-BSomeAction.shadow">
<attr name="originalFile" stringvalue="Actions/Build/org-demo-bla3-BSomeAction.instance"/>
<attr name="position" intvalue="400"/>
</file>
</folder>
</folder>
</folder>
</folder>

The above is already possible with dev builds. Nevertheless, I'm looking forward to being able to do the above via annotations instead of layer entries.

Further reading:

http://bits.netbeans.org/dev/javadoc/org-openide-awt/apichanges.html#Actions.context

http://blogs.sun.com/geertjan/entry/the_continuing_march_of_actionlistener

How do I create an Action that is automatically enabled and disabled depending on the selection?

There are several ways to do this, depending on what exactly you need. The basic problems all of the available solutions are addressing is that:

  • An action may be created and shown in a menu, toolbar or popup menu.
  • While it is visible on-screen, the selected file (or whatever) can change.
  • If it is context sensitive, it should run against the thing it was shown for not whatever is selected at the millisecond when it is actually called
  • People want to write main-menu and toolbar actions which are enabled and disabled based on what is selected - in practice this means writing an object that enables and disables itself based on a particular type — a particular class or its subclasses — being selected (each logical window in NetBeans has its own "selection"; the "global selection" is whatever is selected in whatever window currently has focus)

NetBeans 6.9 allows context-sensitive actions to be registered declaratively in your module'sXML layer file. In the IDE, File > New File > Module Development > Action will generate some rather opaque layer-based registration code for you (on the first page of the wizard, specify that you want a context sensitive action):

    <file name="mypackage-SomeAction.instance">
<attr name="delegate" methodvalue="org.openide.awt.Actions.inject"/>
<attr name="displayName" bundlevalue="mypackage.Bundle#CTL_SomeAction"/>
<attr name="injectable" stringvalue="mypackage.SomeAction"/>
<attr name="instanceCreate" methodvalue="org.openide.awt.Actions.context"/>
<attr name="noIconInMenu" boolvalue="true"/>
<attr name="selectionType" stringvalue="ANY"/>
<attr name="type" stringvalue="org.netbeans.api.project.Project"
/>
</file>

and a somewhat inscrutable ActionListener implementation

 public final class SomeAction implements ActionListener {
private final List<Project> context;
public SomeAction(List<Project> context) {
this.context = context;
}
public void actionPerformed(ActionEvent ev) {
for (Project project : context) {
// TODO use project
}
}
}

which will be called if and only if one or more projects is selected. The good news is that the code is lightweight, simple and works; the bad news is that it is utterly non-obvious how it ever gets called, and doesn't handle more complicated enablement logic.

If you need something more featureful, there are a few options, old and new:


NodeAction

NodeAction is somewhat more flexible, but requires more code to implement. It is just passed the array of activated nodes whenever that changes, and can choose to enable or disable itself as it wishes. Essentially this is just an action that automagically tracks the global Node selection.


Roll your own

The following is relatively simple and affords a way to perform whatever enablement logic you like (NodeAction can do that too, but this might be a little more straightforward and your code doesn't have to worry about nodes at all: DevFaqWhatIsANode). To understand how this works, see DevFaqTrackGlobalSelection:

public class FooAction extends AbstractAction implements LookupListener, ContextAwareAction {
private Lookup context;
Lookup.Result<Whatever> lkpInfo;   public FooAction() {
this(Utilities.actionsGlobalContext());
}   private FooAction(Lookup context) {
putValue(Action.NAME, NbBundle.getMessage(FooAction.class, "LBL_Action"));
this.context = context;
}   void init() {
assert SwingUtilities.isEventDispatchThread()
: "this shall be called just from AWT thread";   if (lkpInfo != null) {
return;
}   //The thing we want to listen for the presence or absence of
//on the global selection
lkpInfo = context.lookupResult(Whatever.class);
lkpInfo.addLookupListener(this);
resultChanged(null);
}   public boolean isEnabled() {
init();
return super.isEnabled();
}   public void actionPerformed(ActionEvent e) {
init();
for (Whatever instance : lkpInfo.allInstances()) {
// use it somehow...
}
}   public void resultChanged(LookupEvent ev) {
setEnabled(!lkpInfo.allInstances().isEmpty());
}   public Action createContextAwareInstance(Lookup context) {
return new FooAction(context);
}
}


Deprecated CookieAction

In many older (pre-NB 6.8) examples you may find CookieAction. It should be (but is not) deprecated. The original info is left here for reference and/or old code maintenance:

CookieAction is used to write actions that are sensitive to what is in the selected Node(s)Lookup. You can specify one or more classes that must be present in the selected Node's Lookup, and some other semantics about enablement.

Being an older class, under the hood it is using Node.getCookie(), so your action will only be sensitive to things actually returned by that method - in other words, only objects that implement the marker interface Node.Cookie can work here.


Not-Yet-Official spi.actions

This module is part of the platform as of 6.8, but has not yet become official API. Nonetheless it is there, it is stable and straightforward to use. The example below opens a visual editor window if an instance of RAFDataObject is selected and has a RandomAccessFile in its lookup:

public final class CustomOpenAction extends org.netbeans.spi.actions.Single<RAFDataObject>
{
public CustomOpenAction() {
super(RAFDataObject.class, "Open", null);
}
@Override
protected void actionPerformed(RAFDataObject target) {
//If an editor is already open, just give it focus
for (TopComponent tc : TopComponent.getRegistry().getOpened()) {
if (tc instanceof RAFEditor && tc.getLookup().lookup(RAFDataObject.class) == target) {
tc.requestActive();
return;
}
}
//Nope, need a new editor
TopComponent editorWindow = null;
editorWindow = new RAFEditor(target);
editorWindow.open();
editorWindow.requestActive();
}
@Override
protected boolean isEnabled(RAFDataObject target) {
//Make sure there really is a file on disk
return target.getLookup().lookup(RandomAccessFile.class) != null;
}
}

Use ContextAction instead of Single to create actions that operate on multi-selections.

 


http://wiki.netbeans.org/DevFaqActionContextSensitive

30.7.10

Nodes API

  • The Nodes API is the third and uppermost layer in the NetBeans Resource Management System.
  • The role of the Nodes API
    • is visual representation of data
  • Connection
    • Closely connected to this API is the Explorer & Property Sheet API
      • Which is the container and manager of nodes.
  • Usage
    • To present data to the user interface of an application
    • to give the user actions, functionality, and properties for interacting with underlying data.
  • Other usage
    • Need not merely present data
      • It can be used for many other things as well.
        • Examples:
          • An action hiding beneath a node could be invoked when the node is double-click.
  • Nodes and Business Logic
    • A node is not typically concerned with business logic
    • Bug focuses on providing a presentation layer, delegating user interaction to action classes and, where applicable, to its related DataObject.
  • Hierarchy of Node subclasses

image

  • AbstractNode
    • Provides the simplest form of the Node class.
    • Use this class to instance a new Node directly, without needing to implement or extend any of the Node classes.
  • FilterNode
    • Creates a proxy Node that delegates its method calls to the original Node.
    • This kind of Node is used when data needs to be displayed in different ways.
  • BeanNode
    • is used to represent a JavaBean.
  • IndexedNode
    • lets its children be organized based on a given index.
  • DataNode
    • Is most commonly used when representing data from files.
    • Is the Node type representing DataObject such as those you learned about in the previous sections.

Node Container

  • Each Node object has its own Children object, providing a container for child nodes, which are the nodes'’s subnodes.
  • The Children object is responsible for the creation, addition, and structuring of child notes.
  • Each node within the Children object has the Node that owns the Children object as its parent.
  • For nodes that do not have their own children, such as our DataNode for MP3 files, we pass in Children.LEAF as an empty container.

Different Children container class variations and their uses

  • Children.Array
    • Superclass for all other Children classes.
    • You should not derive from this class directly.
    • This container class messages its nodes in an Array.
    • The nodes wil be appended at the end of the array and will be delivered in the same order.
  • Children.Keys<T>
    • Typical superclass for your implementation.
    • Nodes are connected with a key.
    • These keys are also used for ordering.
  • Children.Map<T>
    • The nodes are stored in a Map.
    • The nodes are associated with a key.
      • which is also used for deleting nodes
  • Children.SortedArray
    • Extends the Children.Array class with a Comparator
  • Children.SortedMap<T>
    • Extends the Children.Map<T> class with a Comparator.

Actions

  • A node makes a context menu available to the user,
    • allowing context-sensitive actions.
  • A DataNode obtains its context menu’s actions from the DataLoader of the DataObject it represents.
  • A DataLoader defines a MIME-specific folder in the layer file via the method actionContex(),
    • where action are registered.
  • These are read and added automatically to the context menu.
  • For nodes that do not represent DataObject(s)
    • The getActions() method in the Node is used to define the actions in the context menu.
    • Override this method in your class to add

Event Handling

  • To react to Node events, use a PropertyChangeListener, as well as a NodeListener.
    • PropertyChangeListener
      • to be informed of changes to Node properties provided via the getPropertySet() method.
    • NodeListener
      • Can listen to internal node changes, such as changes to the name, the parent node, and the child nodes.
      • The Node class makes a range of property keys available, such as PROP_NAME and PROG_LEAF
  • NodeListener
    • childrenAdded(NodeMemberEvent evt)
    • childrenRemoved(NodeMemberEvent evt)
    • childrenReordered(NodeMemberEvent evt)
    • nodeDestroyed(NodeEvent evt)
    • propertyChange(PropertyChangeEvent evt)
  • NodeAdapter

Implementing Nodes and Children

27.7.10

How to Programmatically Open the New File Dialog in NetBeans

The question of the day comes from Robin, who is from bstek.com in China. He sends the screenshot shown below and wonders how to enable the "New File" dialog to be opened when a button he created is clicked:

There was a discussion on the dev@openide.netbeans.org mailing list sometime ago (click here to jump into it), answering this question. And here's code that I have tried a few minutes ago (in a 6.7 build) that opens the New File dialog. However, note that the New File dialog can only open in the context of a project in NetBeans IDE. In other words, a project must be open and the assumption is that the new file will be created within that project.

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.Action;
import org.openide.ErrorManager;
import org.openide.cookies.InstanceCookie;
import org.openide.filesystems.FileObject;
import org.openide.filesystems.FileUtil;
import org.openide.loaders.DataObject;

public final class SomeAction implements ActionListener {

public void actionPerformed(ActionEvent e) {

Action a = findAction("Actions/Project/org-netbeans-modules-project-ui-NewFile.instance");
a.actionPerformed(e);

}

public Action findAction(String key) {
FileObject fo = FileUtil.getConfigFile(key);
if (fo != null && fo.isValid()) {
try {
DataObject dob = DataObject.find(fo);
InstanceCookie ic = dob.getLookup().lookup(InstanceCookie.class);
if (ic != null) {
Object instance = ic.instanceCreate();
if (instance instanceof Action) {
Action a = (Action) instance;
return a;
}
}
} catch (Exception e) {
ErrorManager.getDefault().notify(ErrorManager.WARNING, e);
return null;
}
}
return null;
}

}

The code above comes straight from the discussion on the mailing list. Alternative approaces are also described there. So, here's hoping this answers the question, Robin! And good luck with your plugin, looks pretty interesting so far.

May 25 2009, 06:26:38 PM PDT Permalink

3 Comments

Trackback URL: http://blogs.sun.com/geertjan/entry/how_to_programmatically_open_the


Comments:

http://blogs.sun.com/geertjan/entry/how_to_programmatically_open_the

File Access and Display

  • To manage, manipulate, and represent data

image

Solutions

  • File System
  • Data System
  • Nodes APIs

Four Layers

  • Presentation Layer
  • Logical Layer
  • Abstraction Layer
  • Physical Layer

File System API

image

  • The NetBeans Platform gives transparent access to files and folders by providing the File System API.
  • … as if the data is stored in the form of a virtual XML file system, such as that used by the System Filesystem, a JAR file, or in a normal folder.
  • Operations
    • Obtaining
    • Creating
    • Renaming
    • Deleting
    • Moving
    • Reading and Writing Files
    • Monitoring Changes
      • Only internal events are monitored

Data System API

  • Provides a logical layer on top of the File Systems API
    • While a FileObject manages its data regardless of type, a DataObject is a wrapper for a FileObject of a quite specific type.
    • A DataObject extends a FileObject with type-specific features and functionalities.
    • These are specified through interfaces or abstract classes: so-called cookies.

image

  • DataObject
    • Implementing and Adding Cookies
    • Using Cookies
    • Providing Cookies Dynamically
    • Creating a DataObject Manually
  • DataObject Factory
  • DataLoader
    • Implementation
    • Registration

Nodes API

image

  • Node Container
    • Actions
    • Event Handling
  • Implementing Nodes and Children

Explorer & Property Sheet API

image

Window System

  • The window system is a framework provided by the NetBeans Platform.
  • It is responsible for the administration and display of all application windows.
  • It allows the user to customize the layout of the user interface.

Introduction

  • The window system is document based.
    • The central section – that is, the editor section – is all about the display of several files in tabs.
    • View sections are placed around the editor section.
    • Components are arranged within the view sections.
  • The window system is comprised of modes.
    • A mode is a NetBeans Platform class that provides a container for window, displayed like a tab.
    • The windows must be subclasses of TopComponent.
    • Evey displayed window is managed by the WindowManager.
    • Windows can be grouped as well.
      • The assembly of the window system is described in the layer file.

Customization

  • You can disable several features to prevent undesired changes by the end user, such as the undocking or closing of windows.
  • Go to the Properties dialog of your NetBeans Platform Application (or Module Suite) and open the category Build –> Window System.

Window: TopComponent

  • Creating a TopComponent
    • Definition and mapping of a TopComponent in the layer file
    • Settings file to declaratively add a TopComponent
    • TopComponent Reference file mapping a TopComponent to a mode
    • Definition of an action for opening a TopComponent
    • Docking a TopComponent into a specific mode programmatically
  • States
    • Different states of a TopComponent
      • opened
      • closed
      • visible
      • invisible
      • active
      • inactive
    • Methods for the different states
      • opened: protected void componentOpened()
      • closed: protected void componentClosed()
      • visible protected void componentShowing()
      • invisible: protected void componentHidden()
      • active: protected void componentActivated()
  • Context Menu
  • Persistence
  • Registry

Docking Container: Mode

  • Creating a mode

image

  • Modifying a Mode

Groups of Windows: TopComponentGroup

  • Creating a TopComponentGroup

Administration: WindowManager

  • findMode(String name)
  • findMode(TopComponent t)
  • findTopComponent(String id)
  • findTopComponentID(TopComponent t)
  • findTopComponentGroup(String name)

Window System Architecture

image

26.7.10

Menu Bar

  • The menu bar of an application based on the NetBeans Platform is created by the NetBeans Platform via the System Filesystem.

 

  • Creating and Adding Menus and Menu Entries
    • Creating an action class for a menu entry
    • Adding a menu entry in the layer file
    • Creating a submenu
  • Inserting Separators
  • Hiding Existing Menu Entries
    • Simply use the layer tree
      • Creating a Custom Menu Bar
      • Important files –> XML Layer –> <this layer in context>
    • Use the NetBeans APIs
      • The Data Systems API
        • Provides the MenuBar class, which is a subclass of JMenuBar, and has the ability to create its content from a DataFolder object.
          • Create a DataFolder
          • Access the System Filesystem via method getDefaultFileSystem()
          • findFolder()

Structure of the NetBeans Application Window

image

Utilities.keyToString() & Utilities.stringToKey()

It can be helpful to look in the Javadoc for the functions Utilities.keyToString() and Utilities.stringToKey(). These are used for encoding shortcuts.

Action Types

  • Always Enabled Actions

image

image

    • Category:
      • The categories represent semantic groupings of the actions.
      • Either select a preexisting category or create a new one.
  • CallableSystemAction
  • CallbackSystemAction
    • Is a subclass of CallableSystemAction
    • Can delegate to another action, which is typically a context sensitive action.
    • Contains no action logic, but delegates to an action performer.
    • Are used especially by global actions – that is, actions that provide different behavior depending on their context.
      • searches
      • copying
      • pasting
      • such global actions are offered out of the box by the NetBeans Actions API.
    • The action performer:
      • Is made available by a Java ActionMap
        • is made available via a Lookup.
      • Is delivered via the getActionMapKey()
      • All classes that derive from JComponent can make use of an ActionMap.
        • That means the NetBeans superclass TopComponent, which creates windows that integrate into NetBeans Platform applications, also has an ActionMap.
  • CookieAction
    • NodeAction
      • Are dependent on nodes
        • A node is the visual representation of a particular piece of data.
        • Each TopComponent (and therefore each window within the NetBeans Platform) can make use of one or many activated nodes.
    • It is precisely these activated nodes that form the context of a CookieAction.
    • Context-sensitivity is constructed from interfaces, which are called cookies.

image

    •  
  • General Context-Sensitive Action Classes
    • Yet another approach:
      • Providing generic context-sensitive action classes with the help of the Lookup class
    • You will not be dependent upon a Node class, nor any other NetBeans superclass, since you will boserve how any class or interface can be used to determine the applicable context of an action.
public abstract class ContextAction<T> extends AbstractAction 
implements LookupListener, ContextAwareAction {
private Lookup context = null;
private Lookup.Result result = null;

public ContextAction(Lookup context) {
init(context);
}
private void init(Lookup context) {
this.context = context;
result = context.lookupResult(contextClass());
result.addLookupListener(this);
resultChanged(null);
}
public void resultChanged(LookupEvent ev) {
setEnabled(result.allItems().size() != 0);
}
public void actionPerformed(ActionEvent e) {
performAction(result.allInstances().iterator().next());
}
public abstract Class contextClass();
public abstract void performAction(T context);
}

NetBeans Platform Actions

  • The NetBeans Platform bases its actions on the Swing Action Framework.
    • Ultimately, every action rests upon Swing’s Action interface.
    • Simplest case:
      • An action class implements the Action interface
    • Straightforward:
      • Extends the AbstractAction class.
  • The NetBeans’ Own Base Classes for Actions

Hierarchy-of-the-NetBeans-Platform-Action-Base-Classes

  • Registry
    • Actions are registered centrally in the layer file of your module, within the Actions folder.
  • Instance:
    • Actions can be used multiple times in different places
    • Only one instance is created.
  • The possibility of toolbar customization.

Using Libraries

  • Library Wrapper Module
    • The whole application is based on modules.
    • It is desirable to integrate the external JAR file in the form of a module.
    • Enhances the consistency of the application as a whole.
    • You can also bundle multiple JAR files into a single module, after which you need no longer put the physical JAR files on the application classpath, as is normally done when developing applications.
  • Two very important things:
    • It marked all packages in the third-party library with the attribute OpenIDE-Module-Public-Packages, making all these packages publicly accessible.
    • Marked the library it found in the ext/ folder with the Class-Path attribute, putting it on the module classpath.
  • It is advisable to always use a library wrapper module when integrating a third-party library into an application.

Module Registry

Collection modules = 
Lookup.getDefault().lookupAll(ModuleInfo.class);


  • ModuleInfo class

    • The module system provides a ModuleInfo class for each module, where all information about modules is stored.
    • The ModuleInfo objects are available centrally via the Lookup, and can be obtained there as above.

  • Information List / getAttribute():

    • name
    • version
    • dependencies
    • current status (activated or deactivated)
    • the existence of service implementations for the current module

  • Being informed of changes / PropertyChangeListener
  • LookupListener

    • Informs you of the installation and uninstallation of modules
Lookup.Result res = Lookup.getDefault().lookupResult(ModuleInfo.class);
result.addLookupListener(new LookupListener() {
public void resultChanged(LookupEvent lookupEvent) {
Collection c = res.allInstances();
System.out.println("Available modules: " + c.size());
}
});
res.allItems(); //initialize the listener

DialogDisplayer & NotifyDescriptor

NotifyDescriptor d = new NotifyDescriptor.Confirmation(
"Do you really want to exit the application?",
"Exit",
NotifyDescriptor.YES_NO_OPTION);
if(DialogDisplayer.getDefault().notify(d) == NotifyDescriptor.YES_OPTION) {
return true;
}else{
return false;
}


  • Dialog API

Lifecycle of a NetBeans Module

  • To influence the lifecycle of a module, implement a module installer.
    • Module System API
    • ModuleInstal class
  • validate():
    • This method is called before a module is installed or loaded.
    • Load sequences, such as the verification of a module license, are set here. Should the sequence not succeed and the module not be loaded, throw an IllegalStateException method. This exception prevents loading or installing the module
  • restored():
    • This method is called when an installed module is loaded. Here, actions required to initialize the module are called.
  • uninstalled():
    • When the module is removed from the application, this method is called.
  • closing():
    • Before a module is ended, this method is called. Here, you also test whether the module is ready to be removed. Only once this is true for all the modules in the application can the application itself shut down. You can, for example, show the user a dialog to confirm whether the application should readlly be closed.
  • close():
    • If all modules are ready to end, this method is called. Here, you call the actions for the successful verification of the module in question.

Module Layer

  • Layer file
    • This is the central configuration file, in which virtually everything is defined that a module adds to the NetBeans Platform. Partly, it can be seen as the interface between the module and the NetBeans Platform, describing declaratively the integration of the module into the NetBeans Platform.
  • Declare:
    • manifest file
      • OpenIDE-Module-Layer: com/galileo/netbeans/module/layer.xml

netbeans-system-filesystem

  • Order of Entries
    • The order in which the entries of the layer file are read (and hence shown in the menu bar) is defined by a position attribute.
  • Instance Files
    • Files of the type .instance in the System filesystem describe objects of which instances can be created. The filename typically describes the full class name of a Java object.
  • Shadow Files
    • .shadow files are a kind of link or reference to an .instance file. They are used mainly when singleton instances of objects, as with actions, are used.
  • Settings Files
    • .settings files are an extracted version of .instance files in the layer file. Information on the type of class and how an instance is created from this class – i.e., information on what these attributes can determine in an .instance file – is defined in a separated XML file.
  • Creating and Using Your Own Contents
    • Your module may use folders, and attributes from the layer file in order to provide extension points to other modules.

Module Manifest

  • Attributes
    • OpenIDE-Module
      • This attribute defines a unique name for the module used for recognition by the module system. The specification of this attribute is mandatory.
    • OpenIDE-Module-Name
      • This defines a displayable name of the module, also displayed in the Plugin Manager.
    • OpenIDE-Module-Short-Description
      • This represents a short functionality description provided by the module.
    • OpenIDE-Module-Long-Description
      • The attribute defines a long description of the module-provided functionality.
    • OpenIDE-Module-Display-Category
      • Modules are summarized into a virtual group with this attribute and thus presented to the user as a functional unit.
    • OpenIDE-Module-Install
      • To run actions at certain times in the modue lifecycle, this attribute sets a module installer class.
    • OpenIDE-Module-Layer
      • This is one of the most important attributes. With it, the path is specified to the layer file describing the module integration into the platform.
    • OpenIDE-Module-Public-Packages
      • To support encapsulation, access to classes from another module is denied by default. This attribute is used to set visible public packages and allow other modules to use these classes. It is especially essential with libraries.
    • OpenIDE-Module-Friends
      • If only certain modules are allowed access to these packages, which are declared as public, then these may be stated here.
    • OpenIDE-Modue-Loalizing-Bundle
      • Here, a properties file is defined, which is used as a localizing bundle.
  • Versioning and Dependencies
    • OpenIDE-Module-Module-Dependencies
    • OpenIDE-Module-Package-Dependencies
    • OpenIDE-Module-Java-Dependencies
    • OpenIDE-Module-Specification-Version
    • OpenIDE-Module-Implementation-Version
    • OpenIDE-Module-Build-Version
    • OpenIDE-Module-Module-Dependencies-Message
    • OpenIDE-Module-Deprecated
    • OpenIDE-Module-Deprecation-Message
  • Services and Interfaces
    • OpenIDE-Module-Provides
    • OpenIDE-Module-Requires
    • OpenIDE-Module-Needs
    • OpenIDE-Module-Recommends
    • OpenIDE-Module-Requires-Message
  • Visibility
    • AutoUpdate-Show-In-Client
    • AutoUpdate-Essential-Module

25.7.10

Module Type

 

 

	<module name="com.galileo.netbeans.module">
<param name="autoload">false</param>
<param name="eager">false</param>
<param name="enabled">true</param>
<param name="jar">modules/com-galileo-netbeans-module.jar</param>
<param name="specversion">1.0</param>
</module>


  • Regular

    • This is the common type of application modul They are oaded on application start. The application loading time is extended by the time of module initialization. Therefore, it is recommended to keep the module initialization very short. Normally it is not necessary to run anything during module loading, as many tasks can be defined declaratively.

  • Autoload


    • These modules are loaded only when another module requires them. Autoload modules correcspond to the priciple of lazy-loading. This mode is usually used for those modules acting as libraries.

  • Eager


    • Eager modules are only loaded when all dependencies are met. This is another option to minimize starting time. For example, if module X depends on the modules A and B, which are not available, it makes no sense to load module X.