Re: The "Presentation" Layer -- WEB400

Dr. Syd Nicholson wrote:

Hi Joe,

I think that your "sooner rather than later" is here now. With products like
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