Re: The "Presentation" Layer -- WEB400

Yes Joe,

I think the big difference between us is that I only have data in the
response from the server. All requests are Ajax based. There is nothing in
the response from the server that defines the data, whether or not to
display it, or what type of field it is. The server has no idea what client
it is talking to, it could be a browser or a web service on another system.

I rely on the "Store" objects in the JavaScript to hold the data
definitions, and JS Widgets o handle the display.

A different approach, but all equally valid.

Syd

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Joe Pluta
Sent: 17 July 2008 16:51
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] The "Presentation" Layer

Dr. Syd Nicholson wrote:

Hi Joe,

I think that your "sooner rather than later" is here now. With products

Ext and Ajax the server only provides data in the form of XML or JSON. The
server knows nothing about the presentation of that data. It is merely a
data source. The server never needs to send any HTML pages to the browser,
with the possible exception of the very first page in the application.

That's right. The data is sent in messages - that's the "decoupling" of
the tiers. There is no UI formatting except at a very abstract level
("this is a numeric field, it has nine digits, please display it" or
"this is a text field of 30 character, it is currently in error, the
message is 'Address required'").

Pages aren't sent, fragments are sent. UIs are made up of three
distinct pieces: the frameworks that draw the widgets, the widgets for
the current view, and the data that populates the widgets. The
separation is pretty straightforward: the first is sent when the user
logs in, the second is sent when the view changes, the third is sent for
every user interaction.

If this is the way of the future, then investing some time learning
JavaScript (especially 'OO' JavaScript) is probably a very good career

move.

Knowing JavaScript is one option, and to me the best one because it
allows much more flexibility. Other options include the various
proprietary client interfaces such as Flex as Silverlight. But those
are very limited options. Given what I've seen with, for example, Dojo,
I don't think the lock-in is worht it.

I find that this is an excellent way to work. The presentation layer is
exclusively browser based, using JavaScript widgets and other derived
JavaScript objects. The server has two layers - one layer comprises the
programs that send/receive data to/from the client (the client interface
layer), and the business layer which comprises a set of service programs
that contain the business logic and the interface to the database itself.

Yes, your client program layer is actually my middle layer above; a set
of intelligent widgets and the code required to access the services
necessary to populate and react to those widgets. The business layer is
on the server, and the client layer talks to the business layer through
UI-independent messages.

Data validation takes place in the business layer and if required error
messages (derived from i5/OS message files and associated APIs) are echoed
back to the client. The values and structure of the XML or JSON sent to

the

browser indicate success or failure and the JavaScript responds

accordingly,

displaying messages if required.

You still need room for some client-side validation, of course.
Preventing alpha data in a numeric field, or identifying required
fields. But definitely all those edits and more should happen
server-side as well. In fact, this is as close to UI dependence as you
get: identifying which field on the UI is in error. This has always
been the difficulty of tiered architectures.

This approach does mean learning how to use the widgets and 'OO'

JavaScript.

However, the effort is well worth the result. Excellent functionality and
really great looking browser pages can be designed quite quickly after the
initial learning curve has been passed.

For now it means you have to learn JavaScript. Check back with me in a
couple of months... <grin> But regardless, learning JavaScript today is
as important as learning Java was a few years ago. You don't have to be
an expert, but the more you know the better equipped you will be.

Joe