Aaron Bartell wrote: ....Isn't that where we should be going with so
much UI layer uncertainty? <<
Amen brother!! Exactly my point ..
Best regards
Niels Liisberg
IceBreak Chief SW Architect
System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: 22. december 2008 17:53
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Pete's web5250
>As much as I appreciate and use green-screen applications myself, I
think
the ultimate answer is to wean ourselves off 5250 in favor of HTML, and
somewhat more intelligent clients, using JavaScript, CSS, and the DOM.
But even with that statement I think we are in trouble, as HTML will
forever be a moving target and instead the controller should really be
built on framework agreed upon interfaces. What I mean by that is you
have data records in and data records out, and also user events. Outside
of that there can be "render kits" (to borrow from JSF terminology) that
can facilitate whatever a shops need is or whatever UI technology is
popular at any given time.
If I have learned one thing since I started developing RPG+CGI apps about
9 years ago it's that the IT industry is *still* struggling to
define/find
a solid GUI that works on a variety of platforms and doesn't screw you
with your choice of the backend language (i.e. when a new GUI layer comes
out, that usually means people jump ship to an entirely new language just
to get the benefits of that new GUI layer vs. being able to stay with
their current backend language).
If such a UI layer was developed right it could be implemented on any
number of platforms using any number of languages. Note I am more
talking
about the client side rendering portions being able to be generic, and
then all the server language would need to do is implement the "spec" of
the UI layer to process data I/O and user events.
Isn't that where we should be going with so much UI layer uncertainty?
Aaron Bartell
http://mowyourlawn.com
Nathan Andelin wrote:
From: Aaron Bartell
The limitation in all of this in my mind is DSPF DDS
specs ... Can anybody think of a way they could be
extensible?
Well, IBM controls DDS, and the corresponding workstation interface, and
I/O opcodes, and ILE compilers, and the 5250 data stream. So I'm not sure
what you expect. Talk to IBM?
As much as I appreciate and use green-screen applications myself, I think
the ultimate answer is to wean ourselves off 5250 in favor of HTML, and
somewhat more intelligent clients, using JavaScript, CSS, and the DOM. Evan
Harris suggested going with a Rich Client like Flex or Silverlight. I'll
steer clear of that, but understand the need for a paradigm shift.
A number of green-screen developers resist the paradigm shift, and call for
IBM to make it easier, but will ultimately need to make some sort of
transition.
To reiterate an earlier post, Pete Helgren had a good idea about helping
end-users make the transition by offering a browser-based runtime
environment with a menu system that enabled access to both 5250 applications
and new Web applications, running within the same context. However, we
never arrived at a really good solution for hosting both.
We used the tn5250j applet, but that had a number of drawbacks. A
JavaScript 5250 emulator [for lack of a better name], like the one Niels is
talking about, would probably be more seamless.
Nathan.
midrange.com
