Very succinct and most informative.
Thanks Joe.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Sunday, 21 February 2010 5:04 p.m.
To: RPG programming on the IBM i / System i
Subject: Re: What skills should you have?
Bryce Martin wrote:
As to how RBD does things. I have no clue, I haven't used it. I use JS
to create DOM elements, sure. That is based on user actions or data
population. But I wouldn't think to create the majority of a page that
way. I've seen mashup code that has all the html, php, and javascript
slammed together in the same document and I really prefer not to develop
that way. My theory is to get that page up as soon as you can and if you
have data to load the user won't care as long as you give them something
"pretty" to look at while it loads. Such as a progress bar or animated
loading gif. But keep your parts seperate and in functional pieces, it
makes it way easier to spot and fix bugs as well as expand on what you
have already.
Actually, the Web 2.0 concept that RBD uses is at first glance exactly
what you say you wouldn't do. You don't write a single bit of HTML; you
use a WYSIWYG designer to create widgets, and then you join those
widgets to create an application. In the best architecture (albeit the
one with the steepest learning curve), the widgets are self-aware - they
call out to the server to reload themselves as needed.
But you really can't do it starting from HTML. That's because the
widgets draw themselves dynamically as needed. Other than the initial
landing page, there really is no HTML. Each application "page" is
really a combination of widgets. But the flexibility is unparalleled:
you create these self-aware widgets and then you can mix and match them
on an application page as needed.
For example, you can have an order list widget. The order list widget
is smart enough to take either a customer or a salesman (or whatever) as
the primary selection criteria. Now you can add the same order widget to
a salesman inquiry or to a customer inquiry. Done! But it requires
some serious infrastructure to do this, and EGL has it. It uses
something called the Infobus, which is a subscribe and publish data bus
that the entire application can use. The order list widget simply
listens for an event. The salesman inquiry page sends a "show salesman
information" event and the order list looks at it and reloads itself.
It's very OO, very modular, very MVC, and more important to me is that
it's VERY, VERY business-enabled. Because the data sent from one module
to another is a record, that makes it very simple for my
business-oriented mind to design.
Joe
As an Amazon Associate we earn from qualifying purchases.