Ability to write a screen only using XML and noting what the service is and the method to call. This would allow the more easily creation of CRUD screens for things like code tables (e.g. Org admin, Academic Time Period.).

Rationale/Background - KS currently has to write controller logics that translates and update button to call the update method in the service for the object. The workaround has been to write the glue code for each controller (using maintainable & lookable). KS doesn't want to have to maintain all that code. But in some cases, KS screens are so complex that we need custom controllers anyway.

I believe KRAD has been looking into having the client call directly to REST/JSON services. I'd be interested in hearing Rice's thoughts on that possible path. This might allow more of a decoupling of the front end, designed with krad beans and the backend.

We need more info here since it's not clear what's wanted here. Peter and Garey should meet and generate user stories so we know what's needed. Also if the estimate is over 200 hours this needs to go to KRRM queue.

please include me in any conversations on theis topic

I chatted with both Garey and Larry this week on this issue.

Garey's take was, in a nutshell, that they want to be able to author pages with KRAD that work more like angular.js pages in that all the back end interaction is done via RESTful services. The wins would be:

• a stronger separation of concerns that frees front end developers from writing custom controllers.
• faster development of new screens
• improved performance and scalability

Talking to Larry, the heart of this request is that instead of dealing with data objects and persistence in KRAD, they would like to be able to configure a screen (e.g. a maint doc) to utilize a RESTful service to handle the CRUD operations on the data. They specifically want to use JSON data formats and client side data binding. This will help KS to achieve its architectural objectives and allow them to develop screens in a way that meets their needs.

A key issue that Larry brought up is one of timing. Currently, 2.6 is the last version of Rice that KS is definitely going to take. After that they will be making their upgrade decisions based on impact that they are willing to accept. That imposes an aggressive time line on us to deliver this functionality if they are going to be able to take advantage of it.

Is client side binding an absolute requirement for this? That requires KRAD to shift to a client side MVC framework, which even if we determined today we wanted to do would take a lot of time. We can get the benefits of Rest services with the server side binding. In fact, you can get 2 of the three mentioned benefits today. The back end can be provided with Rest services that your front end connects to (over the service bus). The only difference is currently you need to translate the data from the Rest services to data objects that KRAD can work with, so it is extra work for developing the screens. However, in general data from the backend needs to be transformed (for the presentation) in some way anyhow, with the exception of Maintenance, Lookup, and Inquiry. The real win I see would be allowing those frameworks to connect directly do a service for its CRUD operations, which is a long standing enhancement we have talked about.