Re: 'green screen' not sellable --> WE(?) are the problem -- MIDRANGE-L

There are also examples at some of the framework sites - like Renaissance, I believe.

One comment - Open Access for RPG is not really a tool for writing web pages - it CAN, and that was the primary focus when it was first presented by IBM as a solution for writing web pages from RPG. But it's really a way to divert the RPG runtime to call your procedure to handle IO - and what you do with that is only limited by your imagination. If that means writing web pages, then you use whatever you want - javascript libraries, all that.

That is greatly over-simplified, I know - but it makes a point, I hope.
Cheers
Vern

On 6/9/2015 1:49 PM, Jon Paris wrote:

I don’t disagree that this might be useful Thomas, but there have been various efforts to do this before. But people tended not to stick with the “simple” examples and in the end they all end up very different and therefore hard to compare. Each vendor or proponent tends to want to highlight their own advantages I suspect.

Last one I recall was via iProDeveloper and was part of (I think) a series on MVC.

Re examples of PHP. You apparently have never looked at the Zend Server Console because there is a tab there marked “Demo Applications” (far right) - it includes not one but two subfile demos the second of which adds an image via an Ajax call-back. There are also various other code samples.

In series of articles "PHP from an RPG Perspective” I wrote an explained a basic subfile example using SQLlite as the database. You can find it here: http://iprodeveloper.com/rpg-programming/php-rpg-perspective-part-4-phpotpourri

In the next part of the series, for comparison purposes, Jeff Olen wrote a DB2 version of the code and Susan Gantner wrote a MySQL version. You can find that and more here: http://iprodeveloper.com/rpg-programming/php-rpg-perspective-part-5-database-access

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 9, 2015, at 1:45 PM, Thomas Burrows <thomas.burrows.1957@xxxxxxxxx> wrote:

Idea

What if everyone that had a solution did a simple example. Say a subfile
type example of adding, updating, and deleting a record. Did the example in
your new coding style, product, etc.

Posted the code to help everyone have some references.

Getting any information on a working example from ZEND is hard. One thing
that holds many programmers back is solutions are smoke and mirrors. We
need the details. I would be willing to help pay for the $50 to %100 a
month where we could put the examples. Maybe some consulting group or
vendor might want to host the site. People need working examples to start
from. Not marketing whatif's.

Off the top of my head I could think of

1. Zend PHP example.
2. C#.Net example
3. RPG Open Access
4. Whatever tools vendors may have or your consulting company pitches

As I said let us keep this simple. Small file that has records being
modified, deleted, and added to that resembles subfile functionality.

From what I have seen on the blog so far everyone has debated that need
skills need to be learned. Okay let us get a way for those skills to be
acquired.

Thomas

On Tue, Jun 9, 2015 at 12:19 PM, Brian May <bmay@xxxxxxxxxxxxxxxxx> wrote:

Just to clarify....

ProfoundUI applications are SPAs. Our framework dynamically renders each
screen using the metadata send from the handler. Technically our products
are one big SPA.

Also, you can build responsive applications using our toolset as well.

UI modernization of existing applications is a starting point. It allows
our customers to move existing applications forward with confidence. They
soon find they can also build new applications in a more modern and modular
fashion, as you describe, but they can continue to use our tooling for UI
design and even our handler to handle interfacing with the UI.

Not pitching our products here, but since they were under discussion, I
felt clarification was warranted.

Brian May
Solutions Architect
Profound Logic Software
http://www.profoundlogic.com
937-439-7925 Phone
877-224-7768 Toll Free

The IBM i Modernization Experts
www.profoundlogic.com

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Tuesday, June 09, 2015 9:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: 'green screen' not sellable --> WE(?) are the problem

Something like Profound UI's tooling seems ideal - no change needed to
the RPG code at all

Nice endorsement, Vern. I agree that Profound has good tools for IBM i
application development and good people supporting them. But I think it is
important to note that there are trade-offs associated with every tool-set
and "modernization" methodology.

Rather than "no change needed to the RPG code at all", a higher priority
might actually be to refactor some code, eliminate some, and replace some
to fit within an application architecture which is more maintainable over
the long run.

Another priority might be to provide a UI which automatically adapts to
all classes of devices (cell phones, tablets, laptops, desktops) rather
than separate "display files" and different applications for different
sized screens. This strategy is known as "responsive UI design".

I like to use <iframe> elements, but having multiple frames in
applications doesn't fit with an Open Access architecture. I advocate for
"single page applications", where each "page" may be divided into many
"containers", where each container has a different layout and different
data; where the content is dynamically "injected" into each container as
needed over the lifespan of the application.

With browser caching as an option, it is possible for developers to decide
whether to refresh a screen by making a server "request", or to just use
what's available in cache.

If green-screens are not sell-able, what makes HTML renderings of the same
applications more so?

I agree that leveraging existing code-bases and skill-sets has value;
hosting applications on IBM i has value. But to fully utilize browser
capabilities, people need to learn to code differently.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.