My Development Environment
How can you switch environments so quickly ?
How can you switch versions so quickly ?
How can you run two versions at once ?
How can you run two GBC versions at once?
How is your development environment configured ?
UPDATE 11 January 2023
Added section on GUI Design Documents.
A question I get asked when showing examples or quickly creating examples is how do I set up my development environment. The question is normally based around the ability to switch environments so quickly, from one version of a Genero product to another.
So as the last Ask-Reuben before Christmas, as my gift to you I thought I’d share some tips you can incorporate in your development environment. This is not a HOW but it might open your eyes to something you had not thought of previously.
In the documentation page on our website, find the Online link for the latest versions of the documentation. I have added these as Bookmarks in my browser so I can access the documentation quicker. I also have a bookmark for frequently accessed pages such as Presentation Styles Reference, GAS Configuration Reference.
In the news area of our website, use the RSS feeds. I use ifttt to look out for changes and to send me notifications when these pages change.
Similarly in our developer forum, I enable forum notifications and get an email notification for each forum post. Often there will be announcements made in the forum and you should hear about them on the day rather than in a weekly or monthly digest.
Download Products Separately
Genero Studio comes bundled with a number of our products. You are not going to install Genero Studio on a customer site! To install products on a customer site you will need to know how to download, install, and configure our individual products.
From the downloads area of our website I download, install, and configure our individual products separately.
I go as far as suggesting to only use the packages bundled with Genero Studio as your learn Genero Studio. Once you have mastered Genero Studio configuration, use the packages bundled with Genero Studio for reference purposes only.
Install Products Separately
When installing a product, I override its default installation directory to include some aspect of the version number in its name. That is instead of
I use a convention like …
/opt/fourjs/fgl/3.10.19 /opt/fourjs/fgl/3.20.14 /opt/fourjs/fgl/4.01.01 /opt/fourjs/fgl/4.01.02 etc
I use the full X.Y.Z version number and avoid the use of words like new, new2, old.
For installation order I try to install in the following order …
- FGL -> GAS -> GRE – reason why is that GRE prompts for FGL and GAS version so it helps if they are installed beforehand
- install GDC before Genero Studio – reason why is that Genero Studio also installs GDC. For some operation systems, if you install the GDC first it registers the applications location where you installed it, rather than inside Genero Studio install directory.
For Genero Browser Client (GBC) I have /opt/fourjs/gbc into which I install each versions runtime folder e.g. opt/fourjs/gbc/4.01.08. I also have a directory /opt/fourjs/gbc/cust into which I install each versions project folder e.g /opt/fourjs/gbc/cust/4.01.08
Use Four Js License Manager
In my development environment, I use Four Js License Manager and configure each installed FGL product to use the same license in the License Manager. This keeps the admin down to simply adding a few lines to fglprofile or fgllicense for each new FGL version.
Configure Products Separately
Where products use port numbers for communication, write information to log directories, I configure them to use a different port number for each version, and to use different directories.
Consider the Rule of Three. (No, not a reference to the movie American Pie). At any one point of time you will have to consider your current version, the version a customer was last on, and your next version. You should be able to switch between at least three versions quickly. Consider …
- A customer might query that some behaviour has changed, so you need to be able to run the program using the previous version and compare to the current version.
- when working on a new version, your developer or QA might query that some behaviour has changed, you need to be able to run your new program against the current version
Each product has a root directory that is the equivalent of $FGLDIR, and in that root directory is a file that begins env… e.g. envcomp. This file contains the minimum environment variables necessary to use that product and will be configured.
When installing FGL I add my license details to fglprofile or fgllicense. I also select SQLite as my default database driver as part of the install but that is only because I tend to work mainly with small examples rather than with a real database. I’d expect most users to have a different default database and select accordingly at install time.
It could be argued that I should not change fglprofile or fgllicense and they are probably right. Instead I should make a copy of the supplied file and point environment variables such as as FGLPROFILE and FGLLICENSE to my file.
Genero Application Server configuration
With each release I take as.xcf and make the following changes to the following resource entries
- change res.gwc.-js to the latest GBC version e.g. 4.01.08
- change res,access.control to ALL, so that the GAS monitor page is visible
- change res.uaproxy.param to –development, so that the GAS runs in development mode
- change res.ic.port.offset to another port number
- change res.ic.admin.port to another port number
- add ALL to res.log.categories_filter so that GAS logs contain full detail
- add a new resource entry named res.gbcdir and set this to directory where I install GBC products e.g. /opt/fourjs/gbc
- change GBC_LOOKUP_PATH entry to include $(res.gbcdir) e.g.
The change to GBC_LOOKUP_PATH means that I can include ?gbc= and pick up any GBC version I have installed in the $(res.gbcdir) directory.
The res.access.control and res.log.categories_filter I only change because it is my development environment. The default values are more suitable for a deployment environment.
Genero Browser Client customisation
The steps above mean I can include ?gbc=[version] in a URL and change GBC versions quickly. When Direct Connection is used, I can also set FGLGBCDIR=/opt/fourjs/gbc/[version] and switch GBC versions quickly.
By installing the project folders into /opt/fourjs/gbc/cust/[version], whenever I do any customisation …
- the customisation source files will be in /opt/fourjs/gbc/cust/[version]/customization/[name]
- the compiled customisation files will be in /opt/fourjs/gbc/cust/[version]/dist/customization/[name]
Hence during customisation I will execute the following
ln -s /opt/fourjs/gbc/cust/dist/customization/[name] /opt/fourjs/gbc/[name]
This means that the customisation files can be found also by ?gbc=[name], and FGLGBCDIR=/opt/fourjs/gbc/[name]
I hit upon these techniques before I learnt about deploying GBC customisations. Using gasadmin deploy will put files in $(res.gbc.deployment) and also give you access to the ?gbc=[name] techniques as well as the ability to set the default so you do not need the ?gbc=[name] argument.
Genero Studio configuration
With Genero Studio configuration, I like to keep the standard configurations as reference. This includes the Configurations, the Genero installations, the Environment sets, the Display Clients, the Application Servers.
What I then do when I add my own equivalents and I use a naming convention so that I can quickly distinguish between what is standard and what is my configuration. For instance the standard compiler/runtime might be “FGL 4.01.02” and points to the FGL bundled within Genero Studio, so my compiler/runtime is named “fgl 4.01.02” and this points to my FGL that I have installed into /opt/fourjs/fgl/4.01.02. I therefore the standard config shipped with Studio begins with capitals and my config is lower case. If I need to I can reference the standard config and see what values it uses. This applies to the Genero instillations, the Display Clients, and the Application Server entries. FGL vs fgl, GDC vs gdc, GAS vs gas.
With the environment sets, I create my own environment sets prefixed with “My”. So I have environment sets named
“My iOS”, “My Android” etc. as equivalent of “iOS’, “Android” respectively. Again this keeps the standard environment sets so I can reference them and allows me to quickly compare my environment sets against the standard.
When it comes to the Configurations, again I keep the standard configurations and I have my own equivalent with its own naming convention that points to my Genero installations, my Display Clients etc. It was a little harder to come up with a name to differentiate so I simply truncate the last part of the version, if “4.01.02 Desktop” is the standard then I have “4.01 Desktop” as my equivalent pointing to the latest Genero installation, Display Client etc
With my configurations, as well as the standard Desktop and Web entries I also have entries for None (Display=None), TUI (Display=Text), and an entry that points to a GDC running on a remote server (I use a Mac so this points to the GDC on a Windows VM).
I also add some dummy configurations that act as little headers to seperate the various versions, 4.01, 3.20, 3.10, 3.00. End results is that my Configurations drop down looks like the adjacent image.
The number of configurations is a balancing act. I could have ones for every maintenance release but I keep the list at about this size. If I need to test an individual maintenance release, I will edit the individual Genero installation, Display Clients, Application Server entry. Only downside is I occasionally forget to set them back and I think I am using version X.Y.Z but I am actually using version X.Y.Z-1
Within Genero Studio I also make use of Code Templates and User Actions.
GUI Design Documents (.4rp, .4fd etc)
By GUI Design Documents I mean files such as .4rp, .4fd which are edited in a GUI editor and are saved as XML.
Unfortunately Genero Studio does not have the ability to work with, and Save As these files as particular versions. For example, when using Genero Studio 4.01, you can’t save one of these files in the 3.10 or 3.20 format. You can open them in these old versions but when the file is saved it will be saved in the latest version format. You will normally get a warning dialog when you open the file.
This means I do need to keep the old version of Genero Studio around for the rare occasion I need to work with these old files. If you are using these older file versions more regularly, you may find an environment with a dedicated version of Genero Studio for each environment is what you require.
As I said at the beginning, this is an illustration of techniques I use. My needs and usage may differ from yours so this is not a “this is what you must do” article. The goal is you might see something in what I do, and think to yourself I had not thought of that, and apply that concept to your development environment.