But the total development time of these frameworks far
exceeds what a single IBM I shop can finance or even has
the specialized knowledge to make.
One of our ASP.NET developers just developed our shop's first mobile web application. It's an SPA built on Angular. The developer had never built an SPA before, and had never used Angular before. The SPA was finished in a few weeks with one developer committed to its development.
I think it will be very feasible for our IBM I developers to develop SPAs using Angular.
The initial learning curve will be challenging. They will need to learn HTML, CSS, JavaScript and the Angular framework. But we have motivated IBM I developers and managers willing to support training. And I think it's worth the investment in terms of where our shop (ASP.NET and IBM I developers) wants to be in the next five to ten years.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Sunday, May 24, 2015 10:45 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications
SPA Client Frameworks
When I wrote don’t try this at home I was referring to writing a homebrewed OO javascript DOM manipulation framework to support SPA applications.
Angular is such a framework but it also depends on jQuery UI components and in many cases Bootstrap for CSS. Ext JS is another framework that contains it all (DOM manipulations, UI components and CSS) in one.
But the total development time of these frameworks far exceeds what a single IBM I shop can finance or even has the specialized knowledge to make.
Lifespan
When I wrote about lifespan I didn’t mean that a web application just goes away after 5 years, I meant that underlying web technologies changes dramatically in 5 years. EXT JS has invented their own class system, Angular 2 has just joined MS Typescript and when ECMAscript 6 is finally released big changes will come again since EXT JS probably would change their class system (once again) and Typescript also will become obsolete.
But there is also the design paradigm that constantly changes. A 5 year old design already looks as “old” today as 5250 – just look at the changes on homepages designs and themes.
I’m myself is a little bit stocked here, my original SPA framework is written in EXT JS 3, EXT JS 4 introduced major changes in the EXT JS class system that requires major rewrites and now I’m waiting for EXT JS 6 that merges EXT JS and Sencha Touch into one client framework. At the same time I cannot allow that all the old EXT JS 3 to be unable to run on the new version. And that brings me to <IFRAME> …
<IFRAME>
There are pro’s and con’s. The cons are that they are hard to deal with in responsive designs. The pros are that they enable applications to be split into sections that then can be assembled into “a system”.
So why split SPA applications into sections? It seems to be conflicting architectures! Here we have to see what we as IBM I shops has to use SPA for. If we look at SPA in a 5250 environment we would have to build our entire menu system and all 1,000+ 5250 programs into one program. Would that be smart and maintainable? Would such a design enable us to run third party applications within our “SPA system design”?
What we actually do is to have a Menu system (Viewport) and then a lot of mini SPA’s that has a program and a related DDS for a number of displays so if we replace “program” with “application” we may have a Work With Application and an Order Entry Application where access is controlled by a Viewport (the menu system).
This enables us to mix functions from different applications written in different programming languages but it has it cons since we in one session only is able to run one program at a time and programs are therefore unable to intercommunicate.
However the 5250 system design has obvious pro’s. We only have to test a single function without having to make complete unit tests to the entire system. We can mix different program languages and different versions in the same system and we can upgrade parts of the system without touching other parts.
By running parts of the GUI SPA in the same design in <IFRAME> that is basically a browser within the browser we can achieve the same. One <IFRAME> may be active with a EXT JS driven APP, another may be active with an Angular driven APP and yet another may be active with a .NET driven APP.
In fact we can build an entire system like we build toys houses in LEGO – while the user still will see the system as an integrated monolith or as “my system”.
Security and user rules adaptions
Another con in building big SPA’s is that it is very hard to build in different user and user group rules that may affect access to functions, partial datasets in a common DB and data on field level but also access to the servers resources (REST services). Many SPA’s simply doesn’t deal with these issues of a Business Applications or in other words they have to be specific programmed into the SPA and thereby they become vulnerable for manipulation since all code in a SPA is public.
In order to deal with these issues we are back again to server generated SPA’s since user rules defined on the server has to affect what code is included in the SPA. While the server centric “old” methods just generated HTML now it also has to generate Javascript to the generated HTML so the SPA doesn’t expose code that may be copied and run and thereby expose the server.
Can it be done? Yes it can, but it opens a new flank in the discussion - what about user rules and security in SPA’s? Does the SPA have to comply with SOX (Sarbanes–Oxley Act) or any other auditing? This is of course not directly aimed at SPA’s but on the whole system design.
SPA framework vs. server side framework.
SPA’s relies heavy on AJAX requests and since these are more or less transparent interfaces to DB tables and BL the security issue requires a server side framework that is able to handle such requests. SOAP, basic REST or other transparent basic middleware is not suitable since user ids and passwords has to be passed in each request and thereby has to be stored in the SPA.
So some kind of session management has to be provided to the SPA by the server and simple security such as OS object security or login security provided by the HTTP server to access server resources on directory level isn’t simply enough for large applications. Besides that the server framework must be able to handle user rules as described above.
This is tricky. On one hand a SPA should be able to be coded with knowing its final server resources (server independent) on the other hand the server resources hold not only raw data (provided by AJAX calls) but also vital information about how the SPA should react to a specific user so the SPA must be configurable by the server at initiation time.
… Just some Sunday thoughts
On Sun, May 24, 2015 at 4:46 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:
I looked at the W3C HTML5 recommendation that discusses iframes:
http://www.w3.org/TR/html5/embedded-content-0.html#the-iframe-element
While iframes are part of HTML5, there are several security warnings
in the W3C recommendation. So, developers who use iframes need to know
how to use them securely.
I found a blog tutorial discussing iframe security:
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
I would not rely on one blpg tutorial, though. I would search for more
information to confirm what the tutorial is saying is accurate and
leaves out nothing of importance.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Saturday, May 23, 2015 3:39 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications
Personally I don't see why using an iFrame should be ruled in or out
of an SPA.
Okay, it just seems like an oxymoron; each <iframe> would be a
separate "page" in one overall application. Script in one frame may
need to reference content in other frames to coordinate behavior. How
might that play with frameworks like Angular JS?
As I indicated earlier, I use <iframe>s; Just wondered if that might
be a "no, no", for SPAs?
--
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.
--
Regards,
Henrik Rützou
http://powerEXT.com <
http://powerext.com/>
--
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
