On 03/31/2012 11:25 PM, Oleg Puzanov wrote:
Hi all,
After playing with Rave for ~1 week I would like to provide some feedbacks
and questions, which may become mutually useful.
Thanks Oleg, valuable feedback it is!
Comments below.
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?
That is a temporary issue. When we started with Rave last year the first goal
was to get something quickly working. JPA was chosen as persistence layer at
that time, but then we already recognized this would need revisiting later when
to support other persistence layers over time.
I think that time has come, not just (only) for your questioning about it, but
because we're starting to introduce other persistence layers and engines pretty
soon. One of those is adding JCR based content integration, but others will come
up pretty quickly as well. I know of at least one participant in Rave who wants
to add support for MongoDB as well...
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...
Yes. That will require some major abstraction work to be done in the Rave core.
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?
There is no exact roadmap (yet) on this, other than it a fundamental goal for
Rave to support such customizations. So in general I'd say: yes. Concretely this
has to be fleshed out yet.
The same question
about MongoDB integration.
See also above, support for MongoDB, and others, is in scope.
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.
Thanks :)
Note though, even on the UI customizations layer I think there is much more
needed. For one thing (and I think you've pointed that out above too), the
current 'plain' Spring MVC solution doesn't scale well IMO.
Right now the Spring Controllers are strictly tied to a specific view as well as
fixed/annotation driven request mapping. Re-usability and customization is
hampered because of that (assuming you'd want to use Spring MVC at all).
Part of a proposal I recently made, http://t.co/lbwHngXQ , is to introduce a
better separation of concerns for this by adding HMVC support, where the request
mapping resolves in a hierarchical (abstract) view *structure* which then drives
the processing of one or more (hierarchical) controllers and resulting in an
aggregated resulting response (view). The (Spring) Controllers then become
reusable components which can be 'assembled' and 'injected' in truly
customizable front-end usage.
This might look a bit like how Lift or Wicket use *html* templates to wire
components to a page, but my goal is to separate the page model/structure from
the actual view rendering itself. Lift, Play, Wicket, as well as Spring MVC,
etc. are IMO too narrow-scoped web frameworks in this respect...
Anyway, this is something we'll start working on shortly, and might not directly
fit your interest (yet), but I thought it good to mention :)
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...
It most certainly will require a higher abstraction layer within Rave, but we're
pretty agile :)
A complete rewrite from scratch however is definitely not the goal.
Rave does have some general goals, an out-of-the-box usable front-end/portal
being one of them. That goal stands and a lot of people are already building on
top of it. So, while I expect some large internal changes coming up, we do
intend for these to be gradual and incremental as much as possible, and if
needed provide some way of migrating to a newer architectural infrastructure.
But we are certainly not ready to declare our current stack 'stable', so not
ready yet for an Apache Rave v1.0 release either.
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.
My suggestion is to go for option 1 and work with us to see how we can
accommodate your customization requirements. Contributions in this respect will
be very much appreciated.
As I said above: customization support is a primary goal for Rave so we're eager
to hear about and, if feasible, accommodate other requirements and use-cases.
How far we can accommodate your requirements I can't say upfront, and support
for our current core technologies like JPA and Spring MVC are definitely here to
stay, but need not be a per-requisite for using Apache Rave.
Thanks a lot in advance. And sorry for all these critics - I'm just trying
to be practical here.
Thanks a lot for that. I prefer pragmatism any time, and your critics are
welcome as well. We're very open to discuss them and see how we can solve it.
Regards, Ate
Regards,
Oleg
[1]
