This document covers the following topics:
NaturalONE is based on the concepts of Eclipse. It uses of a number of Eclipse features, which make up the product NaturalONE.
Eclipse makes use of a workspace into which you put your development work. NaturalONE and other tools downloaded from the Internet also make use of this workspace. The workspace acts as an interface between the different tools. In the Eclipse context, the tools are called "plug-ins" because they extend the functionality of Eclipse far beyond the default installation of Eclipse.
You maximize the productivity in your development lifecycle when your development work is done using the Eclipse workspace. This also provides the opportunity for many developers to work on the same application at the same time, without interfering each other.
NaturalONE has a special name for working in the workspace. This is called "local mode". In local mode, it is possible, for example, to store your sources in a version control system or to make use of other Eclipse-based Software AG products. Developers who are familiar with Java development in Eclipse can easily make use of the Natural tools and are therefore able to develop Natural-based applications within a very short time.
There is another mode, the so-called "Natural server mode", which is very similar to Natural Studio. It offers a GUI environment for direct development on a Natural server. Keep in mind that this mode is not the preferred mode of NaturalONE, and that it is by far not as powerful as the local mode. Why? As mentioned above, when working in local mode, it is possible to use additional tools and functionality from other vendors. This is not the case when working in Natural server mode. In addition, in Natural server mode, each developer working on a library directly affects other developers working on the same library.
See also Different Modes for Developing Natural Applications in the Introduction.
The local mode is the preferred mode. When developing in Eclipse, the major difference between the local mode and the Natural server mode is that with local mode your sources have to be in the workspace. Compared to Natural development as it was done before the release of NaturalONE, this is very much of a "paradigm shift".
When your applications are currently stored on a Natural server, you locate them in the Natural Server view and then add them either to a new project or an existing project in your workspace using the corresponding command in the context menu. This is only done once. When your applications are in the workspace, you may close the Natural Server view because it is literally no longer needed. From now on, you develop your applications in the workspace (in the Navigator view).
In Natural, a cataloged object is the executable (compiled) form of a Natural source. Cataloged objects are not stored in the Eclipse workspace. When you build, rebuild or update your project, your sources are uploaded to the Natural environment and are compiled there.
With NaturalONE, you can manage the Natural environment directly from the workspace. For example, you can execute a program out of the workspace (even if just the Natural source is physically stored there). In this context, the term "Natural environment" includes the local Natural runtime which is installed with NaturalONE and the Natural server environment which is located on another computer. Since the local Natural runtime belongs directly to NaturalONE, it is not visible as a mapped environment in the Natural Server view. NaturalONE keeps the "link" between the source in the workspace and the cataloged Natural object. It knows in which Natural environment (local Natural runtime or Natural server) the appropriate Natural objects are stored and in which library the cataloged Natural objects are located. You may even start a debugging session without having the cataloged object in the workspace. The Natural source itself is sufficient for this purpose.
When you download an application from the Natural Server view to a project in the workspace, the application parameters are also downloaded. You will find them in the project properties. For example, there is information about the server connection itself (such as host name and port number). And there is also information, for example, on the regional settings, parser parameters or steplibs which are associated with the application. Therefore, if you develop or maintain Natural applications in the workspace, you use the same settings as in the Natural environment. When you build your project in the workspace, the sources are transferred to the Natural environment onto the appropriate Natural system file. The Natural environment is "configured" using the previously downloaded parameters and the sources are cataloged.
The workspace is managed by the so-called Natural builder which keeps the information about the application in the workspace. The builder recognizes whether a source has been changed and whether it needs to be cataloged on the server. The builder is able to distinguish between identically named objects which are located in different libraries. It knows the search sequence for any defined steplibs and thus knows where to find the Natural objects that are used by a Natural program.
If you change, for example, a copycode, the builder knows which Natural
objects make use of this copycode. When you build your project, only the
changed copycode is transferred to the server and only the dependent objects
are cataloged. In this case, the builder acts like a very intelligent
CATALL since it includes all steplibs. This is different from the
CATALL system command as it is used on the server which only
processes the objects in the current library.
There is always the need to have an anchor for an application in the workspace. Regardless of whether you develop Java clients, Ajax pages or Natural applications, this anchor is the project. Because the workspace is located somewhere on your PC's disk, the workspace is also the root node of your project structure. What you see in the project can also be found on the disk, with the identical structure and naming. It is important to understand this because the versioning tools, for example, need to know the physical representation of the workspace on the disk.
Eclipse provides the possibility to reference projects. This means that project A may make use of objects in project B. The Natural builder understands this Eclipse functionality and treats each linked project as a different set of steplibs. Therefore, it is very handy to put common Natural application parts (such as data areas, DDMs or API subprograms) into one project and the application parts on which you are working into a separate project.
