E
egarcia
Guest
Your diagram helps to explain the scenario. The thin-client architecture that you are referring to is possible. However, I am not aware of any implementation like that. (A long while back, I considered something similar with TCL/TK to provide a GUI for OpenEdge on Linux.) The limitation on this approach is that if you have a lot of interactivity on the UI there would be a lot of network traffic because the need to go back to the server to process the app logic or you would need to limit the interactivity. You would also need to have a generic model to set/get properties on UI components. Calling methods on UI components would be limited as well because you would either need to provide a way to go back to the client to run the method or push the method execution from the server. For example consider the case of two grids, Order and OrderLine tables where on the row select of the Order table, you would want to calculate the total of the order and show it on a field on the UI and change the color of the field based on whether the available credit allows the order. This means that on the return of the remote onRowSelect, you would need to call the method to set the value and another to set the color, this needs to be expressed somehow in the response from the remote call A variation of this would be the case where the client UI allows adding records/updating records before saving them to the server. Now you would need a way to pass the data of the child grid to the backend (more network traffic). If you want to model the approach, you could use the JavaScript XMLHttpRequest object to go back to the server or if you are using the JSDO, you can use the invoke() operation: - community.progress.com/.../2938.calling-invoke-operations-with-the-jsdo I hope this helps.
Continue reading...
Continue reading...