GS-UI is short for Green Screens UI Library, part of our Modernization Engine. We already wrote about it in Modernization 2.0 series blogs. Here we will describe some interesting features coming in 1st quarter of 2020.
We are preparing an automatic live terminal screen modernization engine which will work out of the box, easy to learn, light, extremely fast yet very powerful.
Full responsiveness is a CSS styling approach which will automatically adjust UI to the screen size. Many other products offering modernization use fixed positioning which for web and especially mobile environment might not be the best approach.
But we do not stop here. Following features and custom HTML tags brings even more power to create multi-size and multi device templates. Let's review them....
Every GS-* element support environment attribute for the element to decide when to render itself. Imagine wide HTML tables for standard desktop and card oriented design for mobile. Both designs on a single page where every tag is rendered under different conditions.
<!-- Show full table on desktop devices only --> <gs-subfile env="desktop"></gs-subfile> <!-- Show every row as data card on mobile devices only--> <gs-autorow env="mobile" template="#tpl-subfile-card"></gs-autorow>
Every GS-* element support orientation attribute for the element to decide if its content will be rendered or not. For an example, when a user rotates screen from portrait to landscape, one design will hide, an alternate design will show up presenting the same data differently.
<!-- Show on desktop and mobile in landscape mode--> <gs-subfile orientation="landscape"></gs-subfile> <!-- Show on mobile only in portrait mode--> <gs-autorow env="mobile" orientation="portrait" template="#tpl-subfile-card"></gs-autorow>
Target tag is a simple yet very powerful element which will decide not only when to render its content on the page but also where to inject the rendered template.
This is very interesting as we can create reusable segments which can be rendered at different places within template based on device type.
<!-- Render to toolbar element if environment is mobile --> <gs-target target="toolbar" env="mobile">...</gs-target> <!-- For mobile render to #toolbar, for desktop render to #footer --> <gs-target mobile="#toolbar" desktop="#footer">...</gs-target> <!-- Render as is only if environment is mobile --> <gs-target env="mobile">...</gs-target>
As almost every gs-* element might use template attribute as a mean for redesigning default elements UI provided with GS-UI library. Additionally, templates might be loaded from remote source, so we can have reusable segments, shared among many screen templates.
<!-- Load from remote and cache only, do not render --> <gs-template dynamic="false" src="/templates/sample.html" template="#tpl-sample">...</gs-template> <!-- Load from remote and render immediately --> <gs-template src="/templates/sample.html" template="#tpl-sample">...</gs-template> <!-- Use cached template from given id location--> <gs-template template="#tpl-sample">...</gs-template>
Subtemplates are injected in other templates. Very powerful concept which use gs-template tag to create reusable designs. Take for an example 20 RPG/COBOL programs using a single display file with 10 defined records where 5 of them are used in all 20 programs. Instead of copy and paste designs to every screen, create a single template named by display/record name. During automatic screen rendering, this template will be injected into rendered page.
This is a simple, yet powerful concept allows mixing manual segments and automatically generated content.
For an example, here are 2 templates for 2 programs using the same display file named DSP001 but different records. Notice shared records HEADER and FOOTER, used in both programs, while SUBFILE and DISPLAY are different. Yes, this is all you might have for a screen. No other HTML. Even better, code in subtemplates might be code automatically generated by our modernization engine as is or with a few manual touches.
<!-- Display with subfile records--> <block> <gs-template src="/templates/MYLIB/DSP001/HEADER.html"></gs-template> <gs-template src="/templates/MYLIB/DSP001/SUBFILE1.html"></gs-template> <gs-template src="/templates/MYLIB/DSP001/FOOTER.html"></gs-template> </block> <!-- Display with record details--> <block> <gs-template src="/templates/MYLIB/DSP001/HEADER.html"></gs-template> <gs-template src="/templates/MYLIB/DSP001/DETAILS.html"></gs-template> <gs-template src="/templates/MYLIB/DSP001/FOOTER.html"></gs-template> </block>
Automatic Screen Definition
Green Screen Server will detect display file used in current terminal screen including list of display records used. This enables creating a unique "path" based on system, partition, library, object, and record list. This "path" can be used for a simple mapping between the detected screen and custom-made template saved on the server.
In example above, two generated templates if modified and saved, will be placed in
while injecting one of the required templates named based on record names from display definition itself...
/SSID/PARTITION/MYLIB/DSPO001/HEADER.html /SSID/PARTITION/MYLIB/DSPO001/DETAILS.html /SSID/PARTITION/MYLIB/DSPO001/SUBFILE.html /SSID/PARTITION/MYLIB/DSPO001/FOOTER.html
Modify Generated Template
In dynamically generated UI screen, one can select UI Template option from main menu to open web based simple HTML editor with support for live screen updates. Once finished, template can be easily saved to the server, and it will become immediately available to all terminal sessions.
Editor is simple HTML editor for now, in future versions we will add more features as helpers to generate template segments as forms, field groups etc. including support to edit individual display record template.
Conditional resource loading
With this short introduction we hope we manage to show you what is coming soon. Automatic modernization engine is coming in the first quarter of 2020. Until then, check out offline demo version in our mobile app or web version here our GS-UI pre-release version.