Re: Why ASP.NET gets no Respect

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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