Lets take a currency code - such a code may be in 10 files and may be in 50
displays and in most cases the description are copied.
If you are able to reduce the description to 1 that are reused you have
saved
59 descriptions or 98.3 % but you have of cource to make 59 simple
references
to the one description, so the saved code are aprox. 90%.
The description should of cource hold sufficient metadata to describe the
entity in any use in the system - but again metadata can be reused such
at a column heading for a query can be reused as column heading in a
spreadsheet, possible values can be used not only to create VALUES in
a display file but also to generate a HTML DROP DOWN etc.etc.
This is of cource far beyond the RPG OA discussion - but it can be done
because it is done.
When I define a PF it just define it by reference:
A UNIQUE
A R WAREC TEXT('Web User')
A WAWUSR R REFFLD(PXWUSR PXDTADCT)
A WAWUSN R REFFLD(PXWUSN PXDTADCT)
A WAWUNA R REFFLD(PXWUNA PXDTADCT)
A WALNGC R REFFLD(PXLNGC PXDTADCT)
A WAMAIL R REFFLD(PXMAIL PXDTADCT)
A WAWUSC R REFFLD(PXWUSC PXDTADCT)
....
Did I write the Field Reference File - nope - it is generated out of
metadata.
WAWUSR looks like this metadata packed in in DDS:
A PXWUSR 30A TEXT('Web User Id. +
A ')
A COLHDG(' ' +
A 'Web User ' +
A 'Id. ')
When i define a grid over the same field I do it by reference to the file
field:
<grid design="BASICGRID" pdf="1" xls="0" csv="1" xml="1" json="1" html="1">
<gridField id="WAWUSR" type="D" comment="Web User Id." locked="true" />
<gridField id="WAWUNA" type="D" comment="Web User Name" locked="true" />
<gridField id="WALNGC" type="D" comment="Language Code" />
<gridField id="WAMAIL" type="D" comment="Mail Address" />
<gridField id="WAWUSC" type="D" comment="Web User Class" />
<gridField id="WAWUSN" type="D" comment="Web User No." />
<gridField id="WAWPWD" type="*" comment="Web Password" />
<gridField id="WARCST" type="*" comment="Record Status Code" />
<gridField id="WARCDC" type="*" comment="Record Delete Code" />
<gridField id="WARCUD" type="*" comment="Record Update Counter" />
</grid>
Did I do any real coding here - nope I just called another API to make
repack
of the same metadata into another coding language and be aware of my file
knows
the reference to the original metadata.
The result by running the reference against the EXT JS grid API would look
like
{header : "Web User Id." ,locked : true ,width : 195 ,dataIndex :
"WAWUSR",align : "left",sortable : true}
where most parameters are fetched from the metadata.
and when I then deploy my autogenerated CRUD service to fill in the grid it
will deliver
related JSON like
WAWUSR : "Henrik"
WAWUSR : "Admin"
Note that the program that evokes the grid dosn't have any bindings to the
CRUD
service it is to completely seperated programs - the bindings lies in the
dataIndex
parameter in the grid and the data passed in the JSON object.
Ohh now I need the field in a form ... i define a refenence
<formField id="WAWUSR" type="I" mandatory="1" comment="Web User Id." />
calls the EXT JS form API that returns the metadate packed in this:
{fieldLabel : "Web User Id." ,labelStyle : "white-space:wrap" ,name :
"WAWUSR" ,maxLength : "30" ,allowBlank : false ,width : 240 ,xtype :
"",vtype : "",qtip : ""
}
Again the CRUD service return a JSON row WAWUSR : "HENRIK" that binds the
data to the field and so on
So it is actually amazing how much juice you can squize out of a single
lemon
even though this is neither mainstream programming.
And the good ting is that it is dynamic - that is if I change my metadata
or parameters
that introduces new behavior it will in most cases be reflected in the
system *IMMED
bacause most code are generated on the fly or it will caught by build in
change mana-
gement.
This is what program production is about - most of the code are
autogenerated and
can be regenerated - but the central metadata rules and since the metadata
covers
all general menues, grids and forms - what is then left?
typically the special order entry program etc. unless you are a programme
that takes
pride in making non standarized programs to trivial tasks.
On Fri, Feb 3, 2012 at 8:59 PM, Douglas Handy <dhandy@xxxxxxxxx> wrote:
My rule of thumb for estimating (mostly because of scope creep) is:
A programmer I knew explained project time overruns as an extension of
the common 80/20 rule:
"The first 80% of the project takes the first 80% of the time. The
last 20% takes the other 80% of the time."
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
midrange.com
