Yeah, Walden. I haven't forgotten about last week's discussion, and business layers.
Regarding server side technology used to generate the UI, it struck me in my study of UI widget libraries this week that most of the process of generating the UI is removed from the server and done instead, in the browser. Rather than responding with HTML, the server responds by sending a wee bit of static HTML and a boatload of static JavaScript. Then the JavaScript immediately makes requests to fill in client-side data stores, and bind them to UI widgets.
So rather than generating an HTML stream, the server generates XML or JSON formatted data streams. The client parses it and loads it into local data stores. And binds it to UI widgets. And local data stores are object based, as opposed to simple data streams. You see browser memory usage climb in Windows Task Manager. Which raises the issue of currency again as more data processing is
transferred from server to client, and the client works with
locally stored result sets. There's a trade off between performance and currency. Locally stored data improves some aspects of performance, although the data in some applications could be stale. This model works well for email. Keep message history in memory. And periodically check for new.
Regarding Prototype, one needs a good tutorial to understand it. And you won't get it be reading the source code. At least, that was the case with me. It might be different for a C++ programmer. The Object Literal notation really threw me off.
When I saw object literals being used in Ext js, I finally decided to get out the the Netscape JavaScript tutorial, and do some playing with it myself. Which brings up the topic of having a code generator if you need to interface with GUI widgets in say, Ext js. It would be a pain to code the object literals yourself every time you needed to define a Grid object, for example. Every brace, colon, comma, quote, and semi colon matter.
Nathan.
----- Original Message ----
From: Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Wednesday, July 16, 2008 10:25:52 PM
Subject: Re: [WEB400] The "Presentation" Layer
To me the bresentation layer would include the js and other client-side tech (flash/silverlight/etc) AND and serverside tech used in generating the UI (asp.net/jsp/php/etc). itZs not until you walk into the business object layer that you leave the presentation layer. But that brings us back to last weeks business objects thrfead :)
As for frameworks. I LOVE prototype, but it's more of a plumbing layer than a UI toolkit. Generally I like to make my own clientside code, but prototype can turn dozens of lines of js into 1 and make it crossbrowser at the same time. Sam's a genius!
I've got a function to make tables zebra striped complete with hover row highlighting that takes nothing more to use than adding the 'zebra' class to a table and making a ZebraPage js call at the end of the page (which is in my standard footer so I don't even need to remember to call it.) I think the entie thing is something like 10 lines of js because of prototype.
-Walden
-Walden
--
Sent from my wireless device.
-----Original Message-----
From: Nathan Andelin <nandelin@xxxxxxxxx>
Sent: 16 July, 2008 19:06
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Subject: [WEB400] The "Presentation" Layer
What do people mean by the "view" or "presentation" layer? In a Web application, I gather that it means the "stuff" that runs in a browser; normally HTML, CSS, and JavaScript. Then add "stuff" that runs in browser plug-ins; like Flash and Silverlight.
Some say that you can include stuff that's hosted or runs on the server, that generates browser output, or processes browser input. That's probably about as far as you can stretch the "presentation layer". At some point you need to distinguish "presentation" from "business" and "data access" layers if you're following a model-view-controller design pattern.
My reason for raising this topic is because I've been reading and pondering about "rich" UI frameworks during the past week. More specifically, I've been looking at Prototype, YUI (Yahoo User Interface Components), GWT (Google Web Toolkit), dojo, Ext js, MooTools, and Open Laszlo. I've been talking with people who are getting into Adobe Flex & ActionScript.
I've been investigating whether to invest time into mastering one of the toolkits, or to continue along my current approach of pairing HTML with CSS and a modest amount of JavaScript.
I'm somewhat impressed with the UI widgets in Ext js. To the point that I got out the JavaScript tutorial and started learning a JavaScript notation called Object Literals, which are used extensively in Ext js & Prototype, and allow developers to define object properties and methods using an abbreviated syntax. Click
http://www.radile.com/rdweb/temp/objects.html to see a example of using "Literals" to define an object containing three properties and a method that writes the property values to the screen.
If I were to adopt Ext js as a toolkit, I'd need to become proficient at writing code like that.
On the other hand, Joe Pluta keeps proclaiming that with EGL, you don't need to learn how to write presentation layer code. The workbench does it for you.
Any thoughts?
Thanks,
Nathan.
midrange.com
