× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Backend language = SQL platform = .Net ( IMHO )

- Maurice O'prey

Sent from my iPhone

On 22 Dec 2008, at 16:53, Aaron Bartell <aaronbartell@xxxxxxxxx> wrote:

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.





--
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.