Ask Reuben
Starting GBC (part 1 of 3)
What is GBC?
What is Universal Rendering?
What is difference between GDC and GBC/UR?
What GBC is used at runtime?
How does GBC work?
With the 4.00 release of Genero Enterprise, Universal Rendering became our standard user interface. We no longer have 4 different front-end renderings produced by 4 different products, Genero Desktop Client (GDC), Genero Browser Client (GBC), Genero Mobile for iOS (GMI), Genero Mobile for Android (GMA). Instead we now have one front-end rendering to get an identical user interface across these GUI front-ends. This was achieved by utilising the Genero Browser Client (GBC) as our standard UI inside the different front-ends. We still have the different front-end products, but for the GDC/GMI/GMA instead of rendering using native widgets and libraries, you can think of these tools as effectively rendering a window with a large Web Component into which the GBC is being rendered. This next series of articles is aimed at those developers who have not used the various iterations of the Genero Web Client / Genero Browser Client and for whom 4.00 and Universal Rendering is their first exposure to the Genero Browser Client. In this first article I will make a series of statements and explain them, I think that will help your understanding of how everything fits together. In the second article I will point out what differences to look out for in your rendered application, and in the third article I will expand on the concept of customization. I am going to use two terms … In our documentations Dynamic User Interface explanation, the right hand side receives the AUI Tree and renders that on the workstation and sends back the users actions. Prior to the 4.00 release, in a typical site of Linux Server, Windows Workstation, this right hand side was typically the gdc executable that was using the Qt libraries (GDC), Android libraries (GMA), iOS libraries (GMI) to render inside the front-ends concept of a window using native widgets. Now with 4.00 a lot of that user interface rendering code has been removed from the GDC executable (and GMI and GMA). Replacing it is the GBC code based on web technologies (gbc runtime package) that is now responsible for rendering the AUI Tree the same and returning the users actions in each of our front-ends. Previously the GBC and its predecessors was only rendered inside a Web Browser as part of our Web solution, now it is being used in all our front-ends. Now the GDC/GMA/GMI code is effectively rendering a single “web component” in a front-end window. Into this “web component” is the gbc runtime package rendering of the AUI Tree and returning the users actions. The GBC uses a Web Browser as the host for the gbc runtime package. These front-ends still retain the ability to perform what is unique for these front-ends. The Genero Mobile front-ends return the ability to interact with the device (take photos etc) via the mobile front calls, as well as their specialised front calls for Android and iOS. The standard front-calls are still implemented by the various front-end clients where possible. It is possible to extend these clients and interact via front-calls. The Mobile front-ends retain the ability to be extended via Cordova plugins. The tools available on the front-ends are still available. For instance with GDC and Universal Rendering, you can still inspect the AUI Tree. You still have the Debug Panel and logging system. You still have the ability to create GDC shortcuts. What has been removed is the Native Rendering, which has been replaced by the Universal Rendering and the use of the gbc runtime package. With GDC and Native rendering, the GDC executable is running and waiting. It receives the AUI Tree and renders the AUI Tree using the compiled code and libraries bundled with gdc executable. With GDC and Universal rendering, the GDC does not have the code to render the AUI Tree inside it. The gbc runtime package sits on your application servers with the rest of your application and is sent to the front-end when the program starts. You will see an example of the gbc runtime package in $FGLDIR/web_utilities/gbc/gbc. When a program using Universal Rendering is started, these web files are shipped to the front-end, and they then start receiving and rendering the AUI Tree, and sending back the user actions. As the gbc runtime package does not sit permanently in the front-end, this has implications on deploying updates. You don’t have to send a whole new GDC, you just need to update what is on the Application Server and configure so that the new gbc runtime package is used. The copy of GBC that sits in FGLDIR/web_utilities/gbc is the last element in the hierarchy of what gbc runtime package is used. You can have your application point at other instances of the GBC. The first place that will be looked at is a gbc folder off your program directory. This will cater for cases where you bundle a gbc runtime package with your compiled Genero application. For mobile applications where you have created packages that bundle your application code with the Genero runner, you are also going to bundle in a gbc runtime package into the App. With gmabuildtool and gmibuildtool you will see there are options (–build-gbc-runtime, –gbc respectively) that enable you to specify what GBC runtimes are bundled in with your app. For desktop and web applications, you may choose to similarly deploy your application with a GBC sitting inside appdir/gbc directory. If you are still using GDC with Direct Connection, that is no Genero Application Server, then the environment variable FGLGBCDIR can be used to control what gbc is used. Note how the documentation specified that first it looks in appdir/gbc, then FGLGBCDIR, and then FGLDIR/web_utilities/gbc/gbc. If you have the Genero Application Server in the mix then that has a few options as detailed here. The important thing to note is the GBC_LOOKUP_PATH and GBC entry in the .xcf. If you study the GBC_LOOKUP_PATH default value of “$(res.path.gbc.user);$(res.gbc.deployment);$(res.fgldir)/web_utilities/gbc”, the $(res.path.gbc.user) entry exists to allow you to specify an additional place to look by using -E when your dispatcher is launched. The $(res.gbc.deployment) is the path where gasadmin and the Deployment App place the GBC when you deploy using those tools. One thing to note with GBC value is if it contains a directory or file, and how if it is a file it contains one line of text with a value. In the default as.xcf, the default GBC value resolves to “_default”, in FGLDIR/web_utilities/gbc you will find a file “_default” that has a line of text “gbc” that is effectively pointing to FGLDIR/web_utilities/gbc/gbc. Also note how you can override with the ?gbc entry in the URL. There are a few options there and it maybe a little daunting at first getting your head around them all. It is also likely that what you use in your development environment is different than what you use in production. For instance in development I find it very useful to have ?gbc= available so that I can switch quickly between different GBCs. Your deployment strategy will probably depend on wether you want to bundle a GBC in with your application, in which case the gbc folder is the place to locate your gbc runtime package. If you want to give yourself the flexibility of different gbc runtime package or shipping gbc runtime package separately then you will use what FGLGBCIDR / GBC_LOOKUP_PATH+GBC+gbc?= give you to allow you to switch between different packages easily. In the Products downloads area, there are two zip files you can download under Genero Browser Client (GBC). The “Runtime package” is the GBC files optimised for runtime. It is the equivalent of what you will find in $FGLDIR/web_utilities/gbc/gbc The “Project package” contains the source files we use to produce the GBC files. Using these files you can modify and produce your own version of the Genero Browser Client, this process is called customization. An interesting exercise is to find the javascript files in each package. In the Runtime package. if you find js/gbc.js you will find that it is 10 lines, 9 lines of copyright whilst the 10th line contains 1,800,000+ characters of minified javascript. In the Project package you will find lots of small .js files. When a customized GBC is built, the contents of these .js files as well as some other files are what is used to create the one gbc.js file which is then minified and compressed (the .gz file). A similar exercise creates the .css in the runtime package from the .css and .scss files in the project package.
Think of gbc runtime package as being the equivalent of the user interface rendering parts of the gdc executable
Think of the user interface rendering parts of the front-end clients GDC/GMI/GMA as containing a form with a single “web component” into which a GBC application is rendered.
The front-end clients (GDC/GMIA/GMA) retain the code that is responsible for communication, tools, standard front-end calls, interfacing with custom front-end calls.
gbc runtime package is not distributed with the front-end clients. It sits somewhere on the Application Server and is sent to the front-end clients when a program starts.
You can control what gbc runtime package is used.
gbc runtime package is javascript that is interpreted, unlike gdc executable which is compiled and executed. You have the ability to create your own gbc runtime package and this is called gbc customisation.