|
Date: Thu, 17 Jul 2008 07:00:10 -0500
From: aaronbartell@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] The "Presentation" Layer
AND and serverside tech used in generating the UI
Walden, this is the key thing to put an "AND" on as you have. Nathan, I
would consider many of the API's you have in your product the presentation
layer API's. In my mind the presentation layer is responsible for a couple
of key things:
1) Mapping/getting data to/from the server language to the UI.
2) Spawning/handling events from the UI back up to/through the server
language to the controller.
In some ways is it maybe just as important to say what the View SHOULD NOT
do. For example, in a lot of RPG-CGI stuff there are links that take you
from CGIPGM1 to CGIPGM2. Or more specifically, CGIPGM1 will output a stream
of HTML that has a link on it, and when the user clicks that link it
immediately takes them to CGIPGM2 (vs. CGIPGM1). This is in contrast to the
development practice I see in *many* (but not all) JSF approaches where most
times every single action a user takes against JSFPGM1 is returned to
JSFPGM1 and based on the evaluation of that action JSFPGM1 will do the
equivalent of a 301 redirect to get the user to the right next page. To get
back to my original statement, the View SHOULD NOT be making directional
decisions (i.e. what page do I go to next?) but instead always hand events
back to the same program that produced the page. When I say "SHOULD NOT"
that might be slightly purist because I don't follow that rule to a "T" as
sometimes the rule needs to be broken to make the framework meet business
needs.
HTH,
Aaron Bartell
On Wed, Jul 16, 2008 at 11:25 PM, Walden H. Leverich <
WaldenL@xxxxxxxxxxxxxxx> wrote:
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.htmlto 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.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
