create an entityeditor

An editor or a detailview is commonly a window, which pops up at certain user interaction with an overview (i.e. mouse doubleclick or selecting a toolbar icon, or the like). AbstractDetailsView already contains most of that.

In special cases it may be useful, to integrate the detailview in the mainview. Then AbstractEditor is the right choice, but we won't fix at the special usecase now.

So we start with the declaration of a sample editor for addresses:

public class AddressesDetails extends AbstractDetailsView<Addresses> {
    private static final long serialVersionUID = 1L;

    public AddressesDetails(String id, Addresses instance) {
        super(id, instance);
    }

    @Override
    public JComponent createView() {
       ...
    }
} 

That's all - for a simple detailview. AbstractDetailsView contains all persistence logic too.

A big point of development time will be consumed by buildding forms, that should be returned by createView. JGoodies takes away most of the grunt work, so it is worth to take a look at jgoodies forms documentation and tutorial.

I'm convinced, that a good starting point is a paper draft of the desired form. That way you think about the elements and their dimensions ...
I will not code a complete mask here, but restrict myself to the principle.

FormLayout layout = new FormLayout("...");
PanelBuilder builder = new PanelBuilder(layout);

builder.setDefaultDialogBorder();
CellConstraints cc = new CellConstraints();

return builder.getPanel(); 

The core of JGoodies forms black magic is FormLayout, which will devide the window area into cells. Each cell may be fixed or dynamic resizable and the rows may be defined or automatically created by JGoodies. I prefer the former, even if it costs more development time. But using selfwritten row definition, you have the complete control over the look of the form - and that's the basic of a good GUI-application. PanelBuilder is used to collect all form-components and when all elements have been attached, builder.getPanel() will create and return the new form.

The extension of SRJRCFrames consists of the management of texts and form components. For both issues an application service will be used:

builder.addLabel(msgSource.getMessage("Addresses." + Addresses.FLD_CITY,
                                      null,
                                      "Addresses." + Addresses.FLD_CITY,
                                      null), cc.xy(1, 1)); 

msgSource is the application service, that provides localized message lookup and can be requested from ApplicationServiceProvider. The services provider is on of the rare factories, that have pulic static methods. In other respects, the usage of public static methods is highly discouraged - that's the responsability of the application context (see Configuration). The factories msgSource (for localized messages) and componentFactory (for consistent creation and look of form components) have been already requested by the Superclass. See code snippets from it:

if (msgSource == null)
   msgSource = ApplicationServiceProvider.getService(
                                 MessageSource.class);
if (componentFactory == null)
   componentFactory = ApplicationServiceProvider.getService(
                                 FormComponentFactory.class);

The Superclass AbstractDetailsView wrapped the entity by a PresentationModel, so for each property a buffered model can be requested (a buffered model helps insulation from uncommited user changes). A textentry will be created like this:

JTextField tCity = componentFactory.createTextField(
                           getPresentationModel().
                           getBufferedModel(Addresses.FLD_CITY));

builder.add(tCity, cc.xyw(3, 1, 5));

A form component may occupy several cells of the form. That's what the CellConstraints are for. This is place for your own researches.