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