Re: Single Page Applications

SO, when something does not work as expected, or fais, you can bounce
blame betwenn two teams.

I think Nathan sugested using Cobol, this will be by far the best
alternative.
More reliable, less downtime, less cost, scalable, easier to develop,
easier to debug, faster, better security...

_______________________________________________________________________
On 05/27/2015 01:02 PM, Kelly Cookson wrote:

I would suggest that client-based frameworks such as Angular JS
should not entirely replace server-based frameworks.

In fact, this appears to be where our shop is heading.

Our shop appears to be heading towards a mix of SPAs and tradition server-side web applications using ASP.NET--with the .NET Data Provider to access DB2 files and stored procedures on the IBM i.

And, instead of having individual COBOL developers create end-to-end solutions, it looks like we might divide responsibilities between: (a) coding browser UIs and SPAs on the client side, and (b) coding traditional web applications and RESTful services on the server side. So, in terms of web and mobile development, some of COBOL developers would become client-side developers and some would become server-side developers (on windows servers). It's a different approach for us than individual developers creating the 5250 green screens and the business logic behind them.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Wednesday, May 27, 2015 11:33 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications

I think you are suggesting that returning JSON data is not as safe and
efficient as returning the html itself. The latter is what you would
be doing in a traditional cgidev2 application, but we have dumped that
method (although it is still supported) in RNS 6.

Of course Brad can speak for himself, but I don't think he was suggesting that one approach was safer or better than the other; just that there are many alternatives for generating browser pages, including server-based and client-based frameworks/techniques.

I would suggest that client-based frameworks such as Angular JS should not entirely replace server-based frameworks. You might continue to use server-based techniques to generate HTML reports (stream files), transform them into PDFs, and stream either format to browser clients.

You get a much more efficient process, and a much faster development
time, if you use the data model approach (basically the JSON) with two
way binding on the visual components. Now the developer can just
arrange components on the page and bind certain elements to data model properties.

Could you be more specific about the efficiency gains and developer productivity? Are you suggesting that client-side tools and utilities streamline development? If so, then how?

The model gets exchanged between the client and the server, and the
RPG part of the process is now lightweight compared to some of the
complicated
cgidev2 programs we used to have.

I understand that, because browser page (UI) generation is being moved from the server to the client.

Our data grid component can do page by page loading, filtering,
sorting on huge files just as easily as a green screen subfile can.

That's good, but it doesn't sound like 2-way binding. Or is it?
--
This is the Web Enabling the IBM i (AS/400 and 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.

-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --