Approach for storing screen definitions
Status: Beta
Brought to you by:
albartell
Menu
▾
▴
#2 Approach for storing screen definitions
Part of the RPGUI effort is to keep the programmer productive. In browser based develop a lot of time can be spent *trying* to get the screen to appear just how you would like it, and many times syntax errors abound. RPGUI aims to be rid of many aspects of having to type out HTML/CSS/Javascript by hand and instead have it generated based on configurations stored in a medium. The approach I (Aaron) feel is the best would be to store the screen definitions in DB2 tables, similar to how we store *DSPF DDS in DB2 tables/members. Note we wouldn't be using a syntax in these RPGUI screen DB2 tables but instead would have tables dedicated to the various artifacts. For example, we would have a top level DB2 table named SCREENPF that would store the high level definition of a screen (i.e. width, height, title, etc). You could equate the SCREENPF being similar to an ExtJS Panel. Next we would have a DB2 table named GRIDPF that would be used to store the header level definition of a data grid and this table would be a child of SCREENPF, linked by an association table. Lastly, in this example scenario, we would have a table named GRIDCOLPF to store the column definitions for the GRIDPF.
The PowerExt appears to have some of this functionality but we need to make sure the license allows the use of that code as I see they have intentions of utilizing a dual-license (i.e. open source and commercial) on the last page of the current user manual: http://issuu.com/powerext/docs/powerext
The DB2 tables for storing screen definitions would only be storing the attributes of a screen and not the actual syntax. The syntax could be ExtJS or XUL or Adobe Flex or JavaFx or Microsoft Silverlight or a custom syntax. I bring this up because that also then means we need to have a mechanism of storing the syntax for any given screen implementation and plugging in the attributes from the DB2 tables. PowerExt takes the approach of using CGIDEV2 to use IFS files to hold text based templates. Another approach would be to have the syntax compiled into an RPG program. Regardless of the approach it would probably be good to cache these definitions in memory and only rebuild them if a change has been made (which means we will need to have a "last changed" timestamp on DB2 table screen definitions so they can be re-cached).
Discussion
You could store all the hierarchical information in a source file member (one per screen) and parse the information when the screen is loaded (and store to a cache if appropriate). Something like the following, maybe:
RPGUI:
version=1.0
SCREEN:
name=EDTCUST
title=Edit Customers
width=400px
height=300px
type=EditableGrid
GRID:
initloadrows=50
columns=3
headers='Item Id','Product Id','List Price'
The source member change date can be used to control re-caching. Since it's all text data, any source file editor (WDSc, RDi, SEU) can be used to edit the information. This makes it very user-friendly.
An advantage is that the information is free-format, so nothing is set in stone in terms of future development - if a new version of RPGUI is developed, that information can be held to make the whole thing backwards-compatible. Of course, a disadvantage is that it's all free-format, so more chances for people to screw it up!
Rory,
There will most definitely have to be some sort of free form configuration because the various UI technologies won't all have the same terms or features. One thought I had would be to make a base set of features that most all UI technologies would have (i.e. width, height, color, etc) and put those in a table where the column name defined the value stored (i.e. WIDTH, HGHT, etc). Then there would be a second table to store "extensions" to any particular UI widget. Of course at this point we are getting into some OO concepts and also it might be better to just have EVERYTHING free form and controlled from admin type applications (i.e. have an admin app for ExtJS, one for Flex, etc, and they would populate the DB2 tables appropriately to eliminate syntax errors).
Aaron
Aaron,
The trouble with having a fixed-format table is that it ALWAYS gets out of date, with new columns having to be added to a separate extension table very quickly. Plus, it's not easy to be able to define which columns are 'basic' for all UI types.
In my opinion, if you're going to have ANY free-format, you may as well make it all free-format, with perhaps a separate parser for each target UI type. And if you're going to do that, a source member is a nice simple way to go.
>The trouble with having a fixed-format table is that it ALWAYS gets out of date,
Quite true. What would be the best free format direction to go? The reason I ask is because there might be a need to store a semi-complex relationship (i.e. parent and child type thing, or call it grouping). Obviously the name-value-pair can work and you just more fully qualify each entry (i.e. form_name, grid_name, grid_width, etc)
What we could really use is somebody with exposure to other UI frameworks other than ExtJS. If you haven't been, check out the thread in the Open Discussion portion of RPGUI and note the problematic licensing we are finding with ExtJS, which might require we jump ship and go with something else.
Aaron Bartell
Aaron
>What would be the best free format direction to go?
Well there are lots of ways you could store this information. For instance, the following is a 'off-the-top-of-my-head' way of defining a screen which contains multiple grids:
:RPGUI
version=1.0
uitype=ExtJS
:SCREEN
name=EDITCUST
title=Edit customers and display employees
width=400px
height=300px
:GRID
gridid=1
type=EditableGrid
title=Customers
url=/rpgui/edtcust
loadrows=50
columns=3
headers='Item Id','Product Id','List Price'
:GRID
gridid=2
type=DisplayGrid
title=Employees
url=/rpgui/dspempl
loadrows=50
columns=2
headers='User Id','Department Id'
Of course, you need more info than this, but you get the idea. A parser can simply parse the entire file creating a 'map' in memory of structures. In this case, when determining to which grid a column belongs (or whatever), rather than using name qualification, you could simply include the 'gridid=grid-identifier' prior to any other definitions, e.g.
:COLUMN
gridid=1
columnid=ItemId
header='Item Id'
title=This is the item identifier
sortable=false
display=always
helptype=popup
helpurl=/rpgui/help/itemid
gridid=2
columnid=EmployeeId
header='Employee Id'
title=This is the employee identifier
sortable=true
display=selective
helptype=popup
helpurl=/rpgui/help/employeeid
linkcolumnid=2
gridid=2
columnid=EmployeeName
header='Employee Name'
title=This is the employee name
sortable=true
display=selective
helptype=none
Like I say, just random thoughts.
Rory
Something additional to consider in this conversation is the reality that eventually it would be good to have UI config files generated based on a drag and drop interface. For example, ExtJS has a screen designer they will be releasing shortly (http://www.extjs.com/blog/2009/10/08/ext-js-designer-preview/?ref=family). Whatever free form syntax we choose we need to make sure it is with auto-generation in mind.
aaronbartell.com