Up to GeneXus 9.0, the developer handled the concept of models: a Design Model containing the logical representation of the system (without an associated physical database, or executable application programs), and one or more Prototype or Production Models, associated to an execution platform.
That is to say, that the design model was not associated to any platform, and the information stored in it was descriptive.
Meanwhile, each prototype or production model was associated to an implementation platform, containing the information of the generator that was going to be used to create the source code in a certain programming language, and the information to provide a logical and physical connection to the DBMS.
This implied a significative difference in the way of work among models. In the design model the developer defines the objects that will be used to describe the system, mainly trough transactions, which are used to extract information to create or adapt the database structures. On the other way, the objects that add behavior to the system, are defined in a prototype or production model.
Any change that was made to a prototype or production model, is automatically copied to the Design model. Any other model will get the changes when it is selected, and GeneXus performs the impact analysis between this model and the Design model. Otherwise the model remains unchanged.
With this way of work, each time the analyst needs to get a model updated, he must select the model and perform the impact changes. There are also some details that should be remarked. The analyst must be aware not to add only comportamental information to design model, (i.e. adding only rules) because when GeneXus performs the Impact Analisys may not find any changes to do to the data base, so the reorganization is not done and the last step of the whole process, the copy model, is not performed either.
As a result of it, changes to the selected prototype or production model are not acomplish. The analyst must force an impact, in order to run the copy model and get the destination model updated.
Once in the target model, the necessary programs should be specified, compiled and, finally, the application is executed in the desired platform, specified by the model parameters.
As we will see, with X it is much easier...
In GeneXus X, the concept of model is replaced with the environment concept. The Environment is the place where the information of the implementation platform is defined, that is to say, the generation language and the database that will be accessed.
In X, the application development work done by the analyst, includes both the objects that describe the system, and those that add behavior. That means, the analyst can work freely instead of thinking what to write where, everything he/she is writing, will be stored in the knowledge base, no matter where.
In other words, now there is only one place to work, not as before, where the information was somehow "splitted" in models. Therefore there is no more "updates" from one model to another. It's as if the design model is combined with a prototype/production model in a transparent way for the user.
When the developer needs to execute the application, he defines the implantation details in the Environment, and commands GeneXus to execute the application (by pressing F5).
With only this user action, GeneXus performs all the necessary steps until the application is executed: changes the database, generates the programs to be executed, compiles them and, finally, executes the application. (See Build Process),
The implementation platform will depends on the environment information.
Several environments can be created to run the application in various platforms. In this case, you just need to select "Set as target environment" on the environment that you want to execute and press F5. This makes "active" the selected environment and the application will be generated with the information stored in that enviroment.
Changing application implementation is as easy as change the active environment.
Yes! It's worth pointing out that the Environments concept already existed in versions older than GeneXus X.
In previous versions, the environments made it possible to define the types of generators that could be used in each model to code the programs in a certain programming language, as well as the type of user interface that would be used when running those programs (Windows or Web).
Each model had a Default Environment that was automatically created together with the Knowledge Base and was used in the creation and reorganization of the database. In addition, several additional environments could be defined.
These environments were created in the Design Model. Then, in the other models it was possible to associate each environment to a certain generator (for example Visual Basic, RPG, and so on) and an execution interface (Windows or Web). In this way, the same environment could have a different definition depending on the model.
In versions older than GeneXus X, the environments were only related to assigning generators and user interfaces. The databases to access were selected by creating Data Stores, which were defined independently from the Environments.
In GeneXus X, on the other hand, when we speak of an Environment we mean everything related to the execution platform, such as the definition of a generator, database access, user interface and other properties of this platform.