Re: Single Page Applications

Yeah, Buck - so there seems no reason to get into using something like CGIDEV2 in such an environment - yes, it can be used to generate other kinds of text files than HTML, but I don't see that happening when the pages are generated with ASP.net and delivered with IIS.

Unless there's another layer here, I don't see using CGIDEV2 unless you are going to serve things with the Apache server on i.

So just stay in the position of providing safe, secure access to IBM i data through stored procedures - they can all be done in whatever language on i.

Of course, with the way the teams are structured as Kelly describes, then maybe there is a need for a vertical combination of those who know IBM i data AND know the delivery end.

Too much fun!

Vern

On 5/28/2015 3:22 PM, Buck Calabro wrote:

On 5/28/2015 3:57 PM, Vernon Hamberg wrote:

Which makes me think of another thing - what you create with CGIDEV2
probably won't be delivered using IIS, right? It'd be the Apache server
on i.

Like Kelly, we have web people and IBM i people and here at least, never
the twain shall meet. All the web stuff is served off of IIS via .NET
mostly in a framework they bought. .NET 'talks' to IBM i strictly via
stored procedures. We really, deeply, madly wanted to avoid having to
include the web people in our database refactoring meetings. [1]

But seems to me you can create end-to-end apps using COBOL and CGIDEV2
procedures - that's all that's needed.

That is all that is needed but I think the political situation at
Kelly's place is such that All Web Stuff Shall Be Done With .NET
regardless of the back end.

[1] Our database has been left as-is for many years and now we're having
real problems fulfilling the needs of the current business climate. As
a result, we're actively refactoring monolithic tables into multiple,
3rd normal form tables joined with proper views and accessed via SQL.
It's not just rejiggering the tables; it's reworking the associated
processes as well. As we alter the database, our IBM i based cross
reference picks up the fact that we have RPG programs (which are stored
procedures) which need attention. We fix them and the web side never
knows the underlying database has been drastically re-arranged.

We like the web team, but the idea of having to teach them how to parse
program described flat files (we still have some) made us all shudder.
And then there's the many arrays (sales week 1, 2, 3, 4, etc, ugh.) It
was just easier all around to expose functionality to them rather than
table layouts.