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





I don't say jQuery is fragile. It's a toolkit.
If you're using jQuery it suggests you are directly building your client side app with Javascript/HTML.This is opposed to GWT, which provides a complete development tool which shields you completelyof Javascript/HTML, and lets you program in Java using tools like Eclipse.
An alternative for GWT could be EGL CE, but the latter is not very popular and has it's "own"programming language, which is never a good sign. And it's more "wizard driven" and not"code driven" (i mean it's more low level but therefore also more powerful and versatile).

From: kevin.turner@xxxxxxxxxxxxxxx
To: web400@xxxxxxxxxxxx
Date: Tue, 11 Jan 2011 09:23:12 +0000
Subject: Re: [WEB400] Turning green-screen apps into web apps

Why would you describe a rich client built with a tried and trusted javascript library as "fragile"?

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of john e
Sent: 11 January 2011 09:08
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Turning green-screen apps into web apps



For robust business apps i wouldn't choose a fragile Javascript/jQuerysolution on the client side. Instead, especially if Java is already used inthe back-end, GWT would be an ideal solution to build the client side.You don't build "pages" in GWT but real ("single page") client apps whichrun in the browser. It's a powerful tool with great integration with thebrowser/HTML/javascript. You can always add some Javascript if necessaryand integrate with jQuery. It also comes with out-of-the-box widgets andit's mature and robust. Development in GWT is in Java, for which powerfuldevtools are available like eclipse, and there is an "eclipse plugin" available.Also, it shields you from all Browser/Javascript quirks and lets you reuseJava code on both the client and the server.

Date: Mon, 3 Jan 2011 15:26:44 -0700
From: pete@xxxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Turning green-screen apps into web apps

Mike,

Personally, I haven't seen anything that can reverse engineer the
existing 5250 code in a way that is truly useful when rendered as HTML.
I wish there was, but even with source code I haven't yet seen a tool
that transforms the 5250 screen into something completely usable that
requires no additional tweaking.

If I had a shop that was very comfortable with HTML, CSS, and
jQuery/JavaScript and was an RPG shop, I'd start from scratch and
redesign the user interface using your client side tools (the
aforementioned HTML, CSS, and jQuery/JavaScript) and use Ajax/JSON as
the data delivery/update method. You might be able to leverage any RPG
you have but even if you rewrote your DB I/O routines in RPG I bet you
would be money ahead in the long run.

It is difficult to predict where the technology overall is going but I'd
bet that front end and back ends will evolve differently so decoupling
the two is essential. The great part about that approach, and one I
discovered after the fact, was that the programs that deliver the
JSON/Ajax data are highly reusable in many different ways. I have two
completely different front end technologies I use but only one back end
servlet that handles the DB I/O. When it was time to write mobile apps,
I already had my back end stuff written so I could concentrate on the
front end details. I simply invoke a URL and it delivers JSON to the
client. The client updates the data the same way, through an Ajax call.

Perhaps the technologies/tools that transform 5250 to HTML use the same
techniques, I don't know. But my experience has been that incrementally
delivering new apps built from the ground up will be more pleasing and
functional to the end user and have greater flexibility than something
reverse engineered from tool.

I originally wrote my substitute dispatch and time management/payroll
software in RPG. My first GUI was in ASP (ugly...too horrible to
recall) and now it is all Java servlets (ONLY because I have four
different DB's to support, 3 of which only run on Windows). But, I
still have users that run BOTH the java servlets AND the good ol 5250
RPG stuff, side by side. So your goal is achievable, you just have to
choose the option that will maximize your client options and leverage
the skills of your shop.

YMMV of course.

Pete Helgren
Value Added Software, Inc
www.asaap.com
www.opensource4i.com


On 1/3/2011 2:13 PM, Mike Wills wrote:
We are starting to look more seriously at making some of our green-screen
apps into intranet apps. The first program would from our payroll software
that is vendor created and supported. Since we don't control the source (in
this case), we cannot take an approach like RPGUI and we would also like to
allow for green-screen usage AND web usage at the same time. I have been
looking at software like Presto from BCD and NewLook from Look Software that
essentially does screen-scraping. I have not tried either one yet.

As I have said on here before, our knowledge base here is RPG and C# and we
would like to avoid PHP if possible so we don't spread out our knowledge
base too thin. We also have a solid base of HTML, CSS, and
jQuery/JavaScript.

1. Do you use this type of software and how do you like it?
2. Which product do you use/like/wish you used instead?
3. How easily customizable is it and do you do any?
4. Could I have an ASP.NET application work with the framework to create a
custom application to interface with a green-screen application?

Also, has anyone done a comparison of each of the options head-to-head to
see where the pluses and minuses are?

I'm sure I'll have more questions, but this is a start. I am just trying to
wrap my head around this better to put together a good proposal.

--
Mike Wills
http://mikewills.me
--
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.


NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



--------------------------------------------------------------------------------


CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
--
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 ...

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.