Re: Why ASP.NET gets no Respect

Nathan Andelin wrote:

A browser UI event may need to trigger client code - a JavaScript function. The event may then need to forward "something" to the server. The event may need to update a variable in, or submit something from a different document in a separate in-line frame. Maybe the event should trigger a complex set of client actions, followed by a series of AJAX interactions.

This is a prime reason why I like the EGL Rich UI interface. EGL Rich UI doesn't intermingle the client side and the server side. Although you use the same syntax (and more importantly the same data definitions), when you write client-side code, it's client code. On the server, you write EGL code to invoke your RPG business logic, but you then expose that as a service (it's a simple push of a button, but the point is that you are in control of the service and its parameters - which means you can also expose that same service as a SOAP service, but I digress).
On the client side, you can attach any event to any function you write, and then if you need to talk to the server, you can invoke any service with a single line of code. The architecture uses callbacks, so you have to understand the concept of event-driven programming, but that's hardly new to anyone writing rich internet applications.
On the other hand, if you *do* like the transparent 5250-like page-at-a-time, you can use the thin client JSF tools. With those, the calls are indeed transparent; you bind a button on the JSF page to a function in your page handler, and it looks as though the call is synchronous. It's not, of course, but if you don't need advanced UI, it's a quick way to get things done.
And of course, the same EGL function that you exposed as a service can be called by the thin client.

There's often a need for some leeway in what code is run on the client and what code is run on the server. It may improve the UI to have additional control on the client - no fixed rule for every case. Other times it may be better for the server to be in control - in which case you don't want a UI event to "trigger" server code, but rather let the server decide which code to run - perhaps based on overall state.

And this to me is pretty much the decision point between rich and thin. If in general your server decides what to do and what to show, you go thin. If, on the other hand, you want more graphically oriented applications that interact more finely with the user, then rich it is.

The nice thing about EGL is that you can do either using the same syntax, and through in SOAP services as well, and all of them can interface with RPG.

Joe