This topic is meant to discuss/debate the way a "screen" is broken down into components so that it can both be represented in a set of DB2 tables but also adhere to multiple UI front end technologies. For example, in my sample code on my machine I currently have three "roughed in" DB2 tables defined that I am going to use to define an ExtJS DataGrid.
SCRPF - a DB2 table that holds the highest level definition which I am terming "Screen", though maybe "Page" would be better?
GRIDPF - a DB2 table that is a child of SCRPF and holds the header level information for any give ExtJS DataGrid.
GRIDCOLPF - a DB2 table that is a child of GRIDPF and holds the definition for each column for a given named DataGrid.
Then from those I could generate an entire .html page (i.e. http://red.rpg-xml.com/rpguifldr/lstitm.html). Generating screens is a much better approach in the end because it eliminates a lot of error prone busy work for the developer. In the case of ExtJS, I found there was a lot to keep track of when dealing with multiple embedded Javascript arrays (which ExtJS makes extensive use of).
In theory you could define a single UI component in the DB2 tables (i.e. customer number prompt) and reference it from multiple screens for the purposes of high reuse factor.
The aforementioned DB2 tables will be placed into the SVN repository in the next few days once I have a simple working example.
Please critique my approach and tell me where I am right, wrong, and otherwise.
So, if I understand this correctly, you are proposing the a page be built based on the contents of a series of database tables? If so, how would you reference business rules (or any other editing rules)? For example, in the case of your LstItm grid, what if there was a business rule that dictated the Product ID had to be in the format XX-YYY-ZZ, and where YYY was a code in another table? While you may somehow be able to code something like that in a column (or even just have a column where you indicate the RPG program to verify a field's contents), I suspect that may be problematic.
The concept of using tables to define the fields that can / should be displayed on a screen makes sense (I have even implemented one - for search purposes only), but I suspect the structure may fall apart when we get to heavy-duty data entry applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This can be done with a combo box. The combo box would use type ahead functionality to produce a list of valid items (like Google suggests search items while you are typing). Also, the configuration option forceSelection to force them to choose a valid code from the list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A combo box only works if you have a table from which to pull valid codes. In the example I was trying to explain, the product ID is *defined* as part of the item and does not have its own table.
Let me give you another example (from our unit of measure sample application).
In our unit of measure table we are going to have fields to allow for the cross-referencing of our U/M code to both the EDI (ANSI standard) and AES (Automated Export System - it's a US thing for imports/exports) codes. I have no intention of creating tables of all of the possible EDI and AES codes (besides there being a significant amount, it would then require someone maintain them). Rather, I simply want to make sure that whatever codes they enter are unique to that unit of measure. Providing combo boxes in this case would be pointless, as the entry *cannot* exist in whatever list we could create. While we may be able to define constraints on these fields to require they be unique (I don't think it can be done using DB2/400, as I believe the limit of unique constraints is 1 per table), it would still mean some kind of monitoring outside of the UI (e.g. the RPG program writing/updating the record).
While I have seen a number of 4GL's / CASE tools attempt to incorporate the defining of business rules in a table, to me they have always been inflexible and/or cumbersome. In my own endeavors down this path, I have even considered having a field reference an RPG program or procedure, but if parameters need to be passed in (especially if they require data other than the contents of the field) making it generic gets messy really fast.
Face it - one of the beauties of RPG is how easy it is to code edits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I misunderstood your explanation before. You're right it would be very difficult to make that edit generic. The only way I can think of doing it is by allowing custom scripts as part of the grid/form. Maybe that could be made part of the GRIDCOLPF? A place to add listeners, in this case the listener would make an ajax query to the rpgle program/procedure to edit the value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This topic is meant to discuss/debate the way a "screen" is broken down into components so that it can both be represented in a set of DB2 tables but also adhere to multiple UI front end technologies. For example, in my sample code on my machine I currently have three "roughed in" DB2 tables defined that I am going to use to define an ExtJS DataGrid.
SCRPF - a DB2 table that holds the highest level definition which I am terming "Screen", though maybe "Page" would be better?
GRIDPF - a DB2 table that is a child of SCRPF and holds the header level information for any give ExtJS DataGrid.
GRIDCOLPF - a DB2 table that is a child of GRIDPF and holds the definition for each column for a given named DataGrid.
Then from those I could generate an entire .html page (i.e. http://red.rpg-xml.com/rpguifldr/lstitm.html). Generating screens is a much better approach in the end because it eliminates a lot of error prone busy work for the developer. In the case of ExtJS, I found there was a lot to keep track of when dealing with multiple embedded Javascript arrays (which ExtJS makes extensive use of).
In theory you could define a single UI component in the DB2 tables (i.e. customer number prompt) and reference it from multiple screens for the purposes of high reuse factor.
The aforementioned DB2 tables will be placed into the SVN repository in the next few days once I have a simple working example.
Please critique my approach and tell me where I am right, wrong, and otherwise.
Thanks,
Aaron Bartell
http://mowyourlawn.com
So, if I understand this correctly, you are proposing the a page be built based on the contents of a series of database tables? If so, how would you reference business rules (or any other editing rules)? For example, in the case of your LstItm grid, what if there was a business rule that dictated the Product ID had to be in the format XX-YYY-ZZ, and where YYY was a code in another table? While you may somehow be able to code something like that in a column (or even just have a column where you indicate the RPG program to verify a field's contents), I suspect that may be problematic.
The concept of using tables to define the fields that can / should be displayed on a screen makes sense (I have even implemented one - for search purposes only), but I suspect the structure may fall apart when we get to heavy-duty data entry applications.
This can be done with a combo box. The combo box would use type ahead functionality to produce a list of valid items (like Google suggests search items while you are typing). Also, the configuration option forceSelection to force them to choose a valid code from the list.
A combo box only works if you have a table from which to pull valid codes. In the example I was trying to explain, the product ID is *defined* as part of the item and does not have its own table.
Let me give you another example (from our unit of measure sample application).
In our unit of measure table we are going to have fields to allow for the cross-referencing of our U/M code to both the EDI (ANSI standard) and AES (Automated Export System - it's a US thing for imports/exports) codes. I have no intention of creating tables of all of the possible EDI and AES codes (besides there being a significant amount, it would then require someone maintain them). Rather, I simply want to make sure that whatever codes they enter are unique to that unit of measure. Providing combo boxes in this case would be pointless, as the entry *cannot* exist in whatever list we could create. While we may be able to define constraints on these fields to require they be unique (I don't think it can be done using DB2/400, as I believe the limit of unique constraints is 1 per table), it would still mean some kind of monitoring outside of the UI (e.g. the RPG program writing/updating the record).
While I have seen a number of 4GL's / CASE tools attempt to incorporate the defining of business rules in a table, to me they have always been inflexible and/or cumbersome. In my own endeavors down this path, I have even considered having a field reference an RPG program or procedure, but if parameters need to be passed in (especially if they require data other than the contents of the field) making it generic gets messy really fast.
Face it - one of the beauties of RPG is how easy it is to code edits.
Sorry, I misunderstood your explanation before. You're right it would be very difficult to make that edit generic. The only way I can think of doing it is by allowing custom scripts as part of the grid/form. Maybe that could be made part of the GRIDCOLPF? A place to add listeners, in this case the listener would make an ajax query to the rpgle program/procedure to edit the value.