Hi all, After playing with Rave for ~1 week I would like to provide some feedbacks and questions, which may become mutually useful.
My goal - to integrate "portal like" behavior for the existing Lift web application, which is written in Scala. Some features are presented as OpenSocial gadgets, which have the following primary use cases: - Gadget Dashboard - main screen where the gadgets are presented, dragged all around, minimized, maximized etc. - Gadget Repository - list of gadgets, which are available for installation / usage Gadgets will consume the available REST API from Lift app + some of them will have more real-time UI behavior (e.g. Activity Feed), so Comet support in Lift will be utilized heavily. High-level view on the original Lift application stack: - HTML, CSS, JS - Lift snippets for UI logic - Service layer - thin wrapper API over MongoDB and Redis, which is implemented with Typed Actors of Akka framework - MongoDB for application data - Redis instances - one for cache, one for message queue I don't want to cover all details of the target architecture here, I just want to mention the key points and problems: 1. What I tentatively plan to drop from Rave: - All JSP files and SpringMVC sources - HTML and Lift snippets to be used instead. But it looks like an effort of several weeks... - All JPA implementations for Repository interface of Rave - MongoDB to be used via service layer API - Domain model classes from Rave Core - JPA entities won't be used here - Service implementation classes from Rave Core 2. What I tentatively plan to keep and to customize: - JavaScript files - to be modified for a new domain model - Some code and interface classes from Rave Core and all interfaces for Shinding and Wookie integrations. But I have one big question here... - Spring core - to be used for binding interfaces to implementations So the main problem is - all repository interfaces and model classes are directly dependent upon JPA. Is this a temporary issue or an original design? Logically, if there is a separation between interfaces and implementations, then JPA implementations should encapsulate all JPA-depedendent code. And interfaces should deal with neutral POJO classes only. Right? The same for model classes... Global question - what is the current roadmap for customization features of Apache Rave? Will it allow a quick and painless integration of the customized data models and 3rd-party data providers? The same question about MongoDB integration. As I see this problem - every portal will need to have its own customized UI, data model and legacy integrations. On the side of UI customizations Apache Rave is almost acceptable, moving to the right direction. Customization of Data Access Layer and Service Layer to fit into the new domain model is very very hard. Looks like a complete rewrite from scratch... For now I'm in the middle between these two options: 1. To apply heavy customizations to Rave 2. To use Shindig directly and to implement the logic for presentation and management of OpenSocial gadgets from scratch Bottom line - what will you suggest by default? Considering my above inputs. Thanks a lot in advance. And sorry for all these critics - I'm just trying to be practical here. Regards, Oleg
