Kelly;
To be bluntly honest I cannot conceive of a reason to change the front end
(View) development away from .Net at this point. I can make all the
religious arguments about being pure IBM i but in this case it's not even a
close call. Your company's talents are in .Net development. It's not even
a COBOL vs. RPG argument either since both will do the job. Arguably,
.Net is the most efficient development environment available today (with
sincere apologies to our brethren in Toronto that work on RDi, that's really
good, but not as good).
To cover the model/controller part of the MVC you can use stored procedures
and/or Web Services (Which I'm sure you already do) to provide security and
performance, and let the front end do what it does. The one change I would
make if it needs to be is to stop any direct SQL from inside the .Net
applications and make them start calling stored procedures and/or Web
Services on the IBM i instance. The pure business logic needs to be vested
in the database and in your COBOL environment.
I'll bet that's not the answer you expected but I think it might be the
correct call.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Kelly Cookson
Sent: Thursday, May 28, 2015 10:41 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications
I have a proposal out to use CGI COBOL in our shop. I don't think it's going
to be accepted.
We've been running our corporate web site on ASP.NET (and accessing the
iSeries as needed) for over 12 years now. We also have a number of custom,
in-house web sites written with ASP.NET and accessing the iSeries as needed.
The question is what are we going to use to start developing web and mobile
applications instead of 5250 green screens.
The question I'm being asked is why would we want to have two ways of
developing web and mobile applications? That means we will have to maintain
two sets of legacy applications and maintain sufficient staff with the right
skills. Add that to the demonstrated success over more than a decade at
using the ASP.NET approach. So why in the world would we want to add COBOL
CGI to the mix? That's the obstacle I have to overcome to sell a CGI COBOL
approach, or an IBM i Integrated Web Services approach, or any approach
other than ASP.NET.
Our development teams are organized by lines of business. So the browser UI
and SPA developers on the client side, and the ASP.NET web application and
services developers on the server side, will actually be on the same team.
The team is responsible for end-to-end application development for their
lines of business. So pointing fingers at each other gets us nowhere. I
think that will be a non-issue for us.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Raul A Jager
W
Sent: Thursday, May 28, 2015 8:53 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 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 --
--
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.
--
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.
midrange.com
