[KULRICE-8867] Applications access data via Rest services versus via direct database access Created: 31/Jan/13 Updated: 16/Jan/15
|Project:||Kuali Rice Development|
|Component/s:||Development, Roadmap, User Experience (UX)|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||William Washington (Inactive)||Assignee:||Unassigned|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|KRAD Feature Area:||
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
For CRUD operations.
Based on conversations with Garey, we would like this to focus on Rest services and how they can be better integrated with KRAD.
|Comment by William Washington (Inactive) [ 01/Feb/13 ]|
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.
|Comment by Garey Taylor [ 04/Feb/14 ]|
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.
|Comment by Jessica Coltrin (Inactive) [ 13/May/14 ]|
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.
|Comment by Larry Symms [ 14/May/14 ]|
please include me in any conversations on theis topic
|Comment by Peter Giles (Inactive) [ 27/Jun/14 ]|
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:
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.
|Comment by Jerry Neal (Inactive) [ 30/Jun/14 ]|
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.