Description of problem: I would suggest to break down AsyncDataProvider and other DataProvider classes to classes based on entities. A similar approach was done with DbFacade class at engine - it contained lots of methods for CRUD operations on engine - these were extracted out to DAOs (VmStaticDao , etc...) I think this will make the code more readable. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
vojtech - can be closed as part of the rest api work?
(In reply to Itamar Heim from comment #1) > vojtech - can be closed as part of the rest api work? Yes, I think we can close this for now. AsyncDataProvider class still contains lots of code, however this code invokes queries via GWT RPC. Assuming oVirt JavaScript SDK initiative, when moving UI to work with REST API, we can do one of following: 1, aggregate helper methods based on logical entity (as suggested by Yair) as part of continual transition to REST API usage 2, move these helper methods (or a subset) into JavaScript SDK itself
going to be resolved via the move to rest api