|
Henrik,
I found a page comparing EXT JS and Angular:
http://www.techferry.com/articles/ExtJS-vs-AngularJS.html
It looks like both are very competent frameworks. They have some
differences, but I think our shop could have used either framework
successfully. I also like the fact that EXT JS is developed and
commercially supported by Sencha.
Since Angular already has it's foot in the door in our shop, that's
probably the direction we will head. But other shops should consider both
EXT JS and Angular (and probably some other frameworks as well, for due
diligence).
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
