I haven't had a chance to play with RDB or EGL for that matter. And maybe
those are useful tools for development. It seems to me there is a lot of
up front work to get the ROI on this type of development. It sounds like
it works best in a shop that is willing to convert their whole development
environment.
How pretty is the finished product? How easy is it to customize the look
and feel of the finished product? Does this require CSS shills? How
about dynamic data support via AJAX? These are questions that could be
answered by myself if I had the software to play with, I'm sure. But that
is not the case for me right now, so I pose these questions. Any great
examples of sites out there that were created via EGL/RDB?
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/20/2010 11:03 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
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
midrange.com
