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 automatic live terminal screen modernization engine which will work out of the box, easy to learn, light, extremly fast yet very powerful.
Full responsivnes is 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 aproach.
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 suport environment attribute for element to decide when to render it self. Imagine wide html table for standard desktop and card oriented design for mobile. Both designs on a single page where every tag is rended 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 element to decide if it's content will be rendered or not. For an example, when user rotates screen from portrait to landscape, one design will hide, 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 simple yet very powerfull element which will decide not only when to render it's content on the page but also where to inject 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 single display file with 10 defiend records where 5 of them are used in all 20 programs. Instead of copy paste desings to every screen, create a single template named by display/record name. During automatic screen rendering, this template will be injected into rendered page.
Thsi 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 automaticaly 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 unique "path" based on system, partition, library, object, and record list. This "path" can be used for a simple mapping between detected screen and custom made template saved on the server.
In example above, two generated templates if modifed and saved, will be placed in
while injecting one of 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 immidatelly 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 grousp etc. including support to edit individual dispaly record template.
Conditional resource loading
With this short introduction we hope we manage to show you what is comming 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-realease version.