Re: Why use PHP? What are the disadvantages? -- WEB400

Nathan,

a Data Dictionary is "just" a repository where you store all your metadata
and can
retreive it by reference. In iSeries it is called a Field Reference File,
in powerEXT
this has been moved into a DB file structure and extended with all the
present needed
information. In the future more decription elements will be added, but
extending is
a far more efficient way to to things than to rewrite it all.

What a Data Dictionary basically does is that it makes it possible to
describe "a
customer number and the roules around it" once and then reuse it in any
aspect just
by reference.

Your DB definition will look like:

<table>
<row id="XAREC" type="physical" key="unique"
description="Application Group">
<tableFields>
<tableField id="XAXAID" reffld="PXXAID" />
<tableField id="XAHEAD" reffld="PXHEAD" />
<tableField id="XALNGC" reffld="PXLNGC" />
<tableField id="XACGIP" reffld="PXCGIP" />
<tableField id="XARPCP" reffld="PXRPCP" />
<tableField id="XARCST" reffld="PXRCST" />
<tableField id="XARCDC" reffld="PXRCDC" />
<tableField id="XARCUD" reffld="PXRCUD" />
</tableFields>
<keyFields>
<keyField id="XAXAID" />
</keyFields>
</row>
<table>

or if you prefer another "packaging":

A UNIQUE
A R XAREC TEXT('Application Group')

A XAXAID R REFFLD(PXXAID PXDTADCT)
A XAHEAD R REFFLD(PXHEAD PXDTADCT)
A XALNGC R REFFLD(PXLNGC PXDTADCT)
A XACGIP R REFFLD(PXCGIP PXDTADCT)
A XARPCP R REFFLD(PXRPCP PXDTADCT)

A XARCST R REFFLD(PXRCST PXDTADCT)
A XARCDC R REFFLD(PXRCDC PXDTADCT)
A XARCUD R REFFLD(PXRCUD PXDTADCT)

A K XAXAID

The UI can be described like:

<design>


<grid design="BASICGRID">
<gridField id="XAXAID" type="D" comment="Application Id."
/>
<gridField id="XAHEAD" type="D" comment="Description" />
<gridField id="XALNGC" type="D" comment="Language Code" />
<gridField id="XACGIP" type="D" comment="CGI path" />
<gridField id="XARPCP" type="D" comment="RPC path" />
<gridField id="XARCST" type="*" comment="Record Status
Code" />
<gridField id="XARCDC" type="*" comment="Record Delete
Code" />
<gridField id="XARCUD" type="*" comment="Record Update
Counter" />
</grid>


<form design="BASICFORM" newRow="1" edtRow="1" cpyRow="1"
dltRow="1" dspRow="1">
<panel id="tab01" label="General Information">
<fieldGroup id="tab01grp01" label="FieldGroup"
visible="0">
<formField id="XAXAID" type="K"
mandatory="1" comment="Application Id." />
<formField id="XAHEAD" type="I"
mandatory="1" comment="Description" />
<formField id="XALNGC" type="I"
mandatory="1" comment="Language Code" />
<formField id="XACGIP" type="I"
mandatory="1" comment="CGI path" />
<formField id="XARPCP" type="I"
mandatory="1" comment="RPC path" />
<formField id="XARCST" type="H"
mandatory="1" comment="Record Status Code" />
<formField id="XARCDC" type="H"
mandatory="1" comment="Record Delete Code" />
<formField id="XARCUD" type="H"
mandatory="1" comment="Record Update Counter" />
</fieldGroup>
</panel>
</form>

</design>

If you stick to the XML definitions, there isn't any platform dependency
neither on
the server or in the client UI - the glue (handler to use the lates
buzzword) that
brings it all together is rather simple methods that based on the XML
templates
mixes metadata from the Data Dictionary with whatever "code" template
(DDS, JSON,
EXTJS) you put it up against. You could even generate a DSPF from this
model.

Now, what if the UI requires a special treat of a field ? The answer is
quite simple,
you just build a field specific template to that field and place it in the
data
dictionary.

Yes, powerEXT API is build in RPGLE for the iSeries, but its basic design
kernel
is platform independent and I already have requests for porting it into
.NET and
PHP.

To answer your more specific question in "what if ?".

If you focus on efficiency in developing large scale applications there
has to be
trade offs - a folkswagon will never be a handbuild mazarati where the
sheik can
order "personalized" features at his wish - especially not without paying
tons of
dollars for them.

Personally I have this with "fancy features" - you should always calculate
the total
cost of the feature (developing, maintaining and supporting them) and
divide the cost
with the number of times the user actual will use them.

To give you an example - a user has redefined the structure of all his
menues and
even given them other names - he has also moved around on all his grid
fields and
now he calls the helpdesk to get help .... "I'm standing in MY menu blabla
in MY
grid blabla and I have a problem - FIX IT !"

My experience in this field is that most users is quite happy with a UI
that is
consistence. Many of your question can actually be solved in Ext JS except
those
that hasn't been invented yet. But Ext JS comes with full source - what
isn't there,
feel free to invent it - many has actually done so - EXT JS has many
extensions called
UX's.

regards
Henrik

Nathan Andelin <nandelin@xxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
19-04-2010 23:25
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>

To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc

Subject
Re: [WEB400] Why use PHP? What are the disadvantages?

Henrik wrote:
powerEXT runs on a Data Dictionary ...

What would you recommend for use cases that aren't covered by the data
dictionary? It seems that we often run into requirements that go beyond
our basic database maintenance models. Maybe it wouldn't work to populate
a drop down list with tens of thousands of options. Maybe users need to
see the longer descriptions of the codes they enter. Maybe they need a
data entry form to retain focus when the tab key is pressed, rather than
navigating to background UI components that may also be on the page. Maybe
a multi page dialog would improve the user experience. Maybe the options
in an account code list must be limited to only those that pertain to an
item selected from another list. Notwithstanding the large component
library available in ExtJS, maybe you come up with a need for one that has
not been invented, yet.

-Nathan.