You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/04/01 16:34:34 UTC
Re: Customization options: data model, service layer and UI
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]
RE: Customization options: data model, service layer and UI
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Oleg Puzanov [mailto:oleg.v.puzanov@gmail.com]
>Sent: Wednesday, April 04, 2012 6:19 PM
>To: users@rave.apache.org
>Subject: Re: Customization options: data model, service layer and UI
>
>Hi Matthew,
>
>Thanks for your comments.
>
>I'm glad that the feature about MongoDB persistence is in the shorter-term
>roadmap of Rave.
>
>Today I had some more time to continue the research about the most optimal
>(longer-term) integration strategy with Apache Rave.
>
>I really don't like such approaches as HMVC or other tightly coupled
>integrations. Because they will definitely lead to maintenance nightmare in
>the future... even for the first upgrade to the next release of Rave. And
>also the current implementation of Rave will need to go through major
>reworks to support such tight integrations and customizations. I would
>rather let Rave stay more focused on its key features than applying some
>large efforts to make it a universally pluggable library for anything.
>
>For my case I'm thinking about the following architecture:
>
>1. Deploy Rave as a separate web app
>2. Use proxy-style integration using Databinder Dispatch code running in
>another web app (Lift app for my case), which will render Rave dashboard in
>a separate <div> on its web page. With Lift this is done with the regular
>bind() method in a snippet, which will map Lift's HTML tag to the
>invocation of Dispatch proxy code.
>3. For sure, JavaScript of Rave dashboard will invoke REST API of Rave
>server directly, no proxying.
>4. Setup SSO infrastructure for authentication and identity federation
>across Lift web app and Rave - Apache Shiro seems to be a good option here.
>5. Minor updates in Rave Portal to work with Shiro (already used now for
>Rave-Shindig integration) + removals of the unnecessary JSP and UI parts to
>keep the dashboard only, I've done this one already.
>
>Benefits of this approach:
>
>1. Easy long-term maintenance - no tight coupling with the internals of
>Rave, painless upgrade process.
>2. Pluggable and flexible architecture:
>
> - Rave dashboard can be embedded into any required UI part with <div>
> - Good separation between the roles of Rave and other web apps - on all
> levels: data, services, UI
> - Straightforward customization options
> - Several Rave instances per single web app are possible
>
>I'm not 100% sure whether all pieces will fit together on practice, but I
>hope that these midnight fantasies are not too far away from the reality :-)
At first blush, it seems like this strategy should work. Please let us know how it goes!
>
>Regards,
>Oleg
>
>
>On Wed, Apr 4, 2012 at 4:47 AM, Franklin, Matthew B.
><mf...@mitre.org>wrote:
>
>> On 4/1/12 6:37 PM, "Oleg Puzanov" <ol...@gmail.com> wrote:
>>
>> >Hi Ate,
>> >
>> >Thanks for your very detailed and positive feedbacks.
>>
>> I want to echo Ate's thanks for your feedback. We definitely want to
>> support your use case and the suggestions/feedback you have provided are
>> important to consider as we work toward our goal of being flexible &
>> customizable. I have some additional comments inline.
>>
>> >
>> >I've added some comments inline below. Plus some other ones here.
>> >
>> >For now I've come up with the following phase #1 integration plan - around
>> >3 man-weeks of effort:
>> >
>> >1. Target approach for UI construction:
>> >
>> > - Master Page - rendered by Lift
>> > - Widget Dashboard area - included into Master Page, rendered by Rave,
>> > placed into <iframe>
>> > - Widget Contents (actual app UI) - rendered again by Lift
>> >
>> >2. Integration approach:
>> >
>> > - Rave is used as a rending engine for Dashboard area only, everything
>> > else is handled by Lift, including "Widget Store" functionality.
>> > - Rave and Lift are running as separate server instances - no such
>> > things as HMVC to present Lift and Rave as a single web application, at
>> > least for now.
>> > - Slightly modified default JPA implementation of Repository interfaces
>> > - Separate PostgreSQL instance to be introduced for Portal UI
>> > configuration data - pages, layouts, regions, widgets etc.
>> > - MongoDB to be used for the actual data of applications / gadgets
>> >
>> >3. Important refactoring for better layering and module separation in
>> >Rave:
>> >
>> > - Better separation between "rave-core" and "rave-web" modules -
>some
>> > parts are specific to the demo web application and should not be
>> >present in
>> > "rave-core". For example: Person and Address classes.
>> > - Repository interfaces and their usage to be aligned across all Rave
>> > modules
>> > - JavaScript changes - the same here: core and demo app parts should be
>> > Separated
>>
>> All good points
>>
>> >
>> >For now I see the following modules in Rave and their roles:
>> >
>> > - Portal Rendering Engine:
>> > - Page Container - JavaScript libraries to draw the widget
>> >dashboards
>> > - Portal Builder - invokes Portal Configuration Repository to build
>> > the portal pages
>> > - Widget Container - dialog to draw the actual widget contents and
>> > toolbars with minimize, maximize, delete buttons
>> > - Portal Configuration Repository - data model and persistence for
>> > pages, layouts, regions, widgets etc.
>> > - Widget Providers Framework - integrations with Shindig and Wookie
>> > - Demo portal application - current web app bundled with Rave
>> > Distribution
>>
>> We are going to start some heavier discussions soon on the dev list
>> regarding architectural decisions (project organization being one of
>> them). You are more than welcome to join in, if you like.
>>
>> >
>> >Portal Rendering Engine and Portal Configuration Repository will be the
>> >default integration points for 3rd-party web applications. Demo portal
>> >parts should be kept separately for not messing with the core sources.
>> >
>> >Regards,
>> >Oleg
>> >
>> >
>> >On Sun, Apr 1, 2012 at 5:34 PM, Ate Douma <at...@douma.nu> wrote:
>> >
>> >> 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...
>> >>
>> >
>> >
>> >> [Oleg] JCR is a brilliant idea. It will enable a data-driven portal UI,
>> >> which can be built with any JCR-compliant CMS. The only major concern
>> >>here
>> >> - performance and scalability of JCR. For enterprise-scale deployments
>> >>of
>> >> Rave it may be suitable. But for web-scale deployments of Rave with
>> >> millions of users and billions of data records it may become a real
>> >> bottleneck. MongoDB based Repository is a better option for such
>needs.
>>
>> I am working on a MongoDB persistence layer that I would like to have in a
>> working state by June.
>>
>> >>
>> >
>> >
>> >>
>> >> 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.
>>
>> Major, but doable.
>>
>> >>
>> >>
>> >>
>> >>> 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 :)
>> >>
>> >> [Oleg] I've read through this e-mail thread about JCR and HMVC
>> >suggestions. Both of them are very interesting and correct approaches.
>> >Especially the view on integrating Spring MVC controllers and other
>> >frameworks like Lift or Play. It will be also very useful to architect the
>> >integrations when Rave is a child web app, which is hosted in a parent web
>> >app - like my case about Lift app. I think that such cases will be more
>> >frequent than having Rave as a parent web app.
>> >
>> >
>> >
>> >> 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.
>> >>
>> >
>> > [Oleg] Yes, this is what I'm trying to do now - option #1. And overall
>> >it looks like the integration effort is not that much tremendous. For
>> >sure,
>> >using <iframe> for Gadget Dashboard is not that kind of integration, which
>> >will cover 100% of requirements. But it will be more than fine for phase
>> >#1.
>> >
>> >
>> >
>> >> 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]
>> >>
>>
>>
Re: Customization options: data model, service layer and UI
Posted by Oleg Puzanov <ol...@gmail.com>.
Hi Matthew,
Thanks for your comments.
I'm glad that the feature about MongoDB persistence is in the shorter-term
roadmap of Rave.
Today I had some more time to continue the research about the most optimal
(longer-term) integration strategy with Apache Rave.
I really don't like such approaches as HMVC or other tightly coupled
integrations. Because they will definitely lead to maintenance nightmare in
the future... even for the first upgrade to the next release of Rave. And
also the current implementation of Rave will need to go through major
reworks to support such tight integrations and customizations. I would
rather let Rave stay more focused on its key features than applying some
large efforts to make it a universally pluggable library for anything.
For my case I'm thinking about the following architecture:
1. Deploy Rave as a separate web app
2. Use proxy-style integration using Databinder Dispatch code running in
another web app (Lift app for my case), which will render Rave dashboard in
a separate <div> on its web page. With Lift this is done with the regular
bind() method in a snippet, which will map Lift's HTML tag to the
invocation of Dispatch proxy code.
3. For sure, JavaScript of Rave dashboard will invoke REST API of Rave
server directly, no proxying.
4. Setup SSO infrastructure for authentication and identity federation
across Lift web app and Rave - Apache Shiro seems to be a good option here.
5. Minor updates in Rave Portal to work with Shiro (already used now for
Rave-Shindig integration) + removals of the unnecessary JSP and UI parts to
keep the dashboard only, I've done this one already.
Benefits of this approach:
1. Easy long-term maintenance - no tight coupling with the internals of
Rave, painless upgrade process.
2. Pluggable and flexible architecture:
- Rave dashboard can be embedded into any required UI part with <div>
- Good separation between the roles of Rave and other web apps - on all
levels: data, services, UI
- Straightforward customization options
- Several Rave instances per single web app are possible
I'm not 100% sure whether all pieces will fit together on practice, but I
hope that these midnight fantasies are not too far away from the reality :-)
Regards,
Oleg
On Wed, Apr 4, 2012 at 4:47 AM, Franklin, Matthew B. <mf...@mitre.org>wrote:
> On 4/1/12 6:37 PM, "Oleg Puzanov" <ol...@gmail.com> wrote:
>
> >Hi Ate,
> >
> >Thanks for your very detailed and positive feedbacks.
>
> I want to echo Ate's thanks for your feedback. We definitely want to
> support your use case and the suggestions/feedback you have provided are
> important to consider as we work toward our goal of being flexible &
> customizable. I have some additional comments inline.
>
> >
> >I've added some comments inline below. Plus some other ones here.
> >
> >For now I've come up with the following phase #1 integration plan - around
> >3 man-weeks of effort:
> >
> >1. Target approach for UI construction:
> >
> > - Master Page - rendered by Lift
> > - Widget Dashboard area - included into Master Page, rendered by Rave,
> > placed into <iframe>
> > - Widget Contents (actual app UI) - rendered again by Lift
> >
> >2. Integration approach:
> >
> > - Rave is used as a rending engine for Dashboard area only, everything
> > else is handled by Lift, including "Widget Store" functionality.
> > - Rave and Lift are running as separate server instances - no such
> > things as HMVC to present Lift and Rave as a single web application, at
> > least for now.
> > - Slightly modified default JPA implementation of Repository interfaces
> > - Separate PostgreSQL instance to be introduced for Portal UI
> > configuration data - pages, layouts, regions, widgets etc.
> > - MongoDB to be used for the actual data of applications / gadgets
> >
> >3. Important refactoring for better layering and module separation in
> >Rave:
> >
> > - Better separation between "rave-core" and "rave-web" modules - some
> > parts are specific to the demo web application and should not be
> >present in
> > "rave-core". For example: Person and Address classes.
> > - Repository interfaces and their usage to be aligned across all Rave
> > modules
> > - JavaScript changes - the same here: core and demo app parts should be
> > Separated
>
> All good points
>
> >
> >For now I see the following modules in Rave and their roles:
> >
> > - Portal Rendering Engine:
> > - Page Container - JavaScript libraries to draw the widget
> >dashboards
> > - Portal Builder - invokes Portal Configuration Repository to build
> > the portal pages
> > - Widget Container - dialog to draw the actual widget contents and
> > toolbars with minimize, maximize, delete buttons
> > - Portal Configuration Repository - data model and persistence for
> > pages, layouts, regions, widgets etc.
> > - Widget Providers Framework - integrations with Shindig and Wookie
> > - Demo portal application - current web app bundled with Rave
> > Distribution
>
> We are going to start some heavier discussions soon on the dev list
> regarding architectural decisions (project organization being one of
> them). You are more than welcome to join in, if you like.
>
> >
> >Portal Rendering Engine and Portal Configuration Repository will be the
> >default integration points for 3rd-party web applications. Demo portal
> >parts should be kept separately for not messing with the core sources.
> >
> >Regards,
> >Oleg
> >
> >
> >On Sun, Apr 1, 2012 at 5:34 PM, Ate Douma <at...@douma.nu> wrote:
> >
> >> 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...
> >>
> >
> >
> >> [Oleg] JCR is a brilliant idea. It will enable a data-driven portal UI,
> >> which can be built with any JCR-compliant CMS. The only major concern
> >>here
> >> - performance and scalability of JCR. For enterprise-scale deployments
> >>of
> >> Rave it may be suitable. But for web-scale deployments of Rave with
> >> millions of users and billions of data records it may become a real
> >> bottleneck. MongoDB based Repository is a better option for such needs.
>
> I am working on a MongoDB persistence layer that I would like to have in a
> working state by June.
>
> >>
> >
> >
> >>
> >> 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.
>
> Major, but doable.
>
> >>
> >>
> >>
> >>> 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 :)
> >>
> >> [Oleg] I've read through this e-mail thread about JCR and HMVC
> >suggestions. Both of them are very interesting and correct approaches.
> >Especially the view on integrating Spring MVC controllers and other
> >frameworks like Lift or Play. It will be also very useful to architect the
> >integrations when Rave is a child web app, which is hosted in a parent web
> >app - like my case about Lift app. I think that such cases will be more
> >frequent than having Rave as a parent web app.
> >
> >
> >
> >> 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.
> >>
> >
> > [Oleg] Yes, this is what I'm trying to do now - option #1. And overall
> >it looks like the integration effort is not that much tremendous. For
> >sure,
> >using <iframe> for Gadget Dashboard is not that kind of integration, which
> >will cover 100% of requirements. But it will be more than fine for phase
> >#1.
> >
> >
> >
> >> 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]
> >>
>
>
Re: Customization options: data model, service layer and UI
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 4/1/12 6:37 PM, "Oleg Puzanov" <ol...@gmail.com> wrote:
>Hi Ate,
>
>Thanks for your very detailed and positive feedbacks.
I want to echo Ate's thanks for your feedback. We definitely want to
support your use case and the suggestions/feedback you have provided are
important to consider as we work toward our goal of being flexible &
customizable. I have some additional comments inline.
>
>I've added some comments inline below. Plus some other ones here.
>
>For now I've come up with the following phase #1 integration plan - around
>3 man-weeks of effort:
>
>1. Target approach for UI construction:
>
> - Master Page - rendered by Lift
> - Widget Dashboard area - included into Master Page, rendered by Rave,
> placed into <iframe>
> - Widget Contents (actual app UI) - rendered again by Lift
>
>2. Integration approach:
>
> - Rave is used as a rending engine for Dashboard area only, everything
> else is handled by Lift, including "Widget Store" functionality.
> - Rave and Lift are running as separate server instances - no such
> things as HMVC to present Lift and Rave as a single web application, at
> least for now.
> - Slightly modified default JPA implementation of Repository interfaces
> - Separate PostgreSQL instance to be introduced for Portal UI
> configuration data - pages, layouts, regions, widgets etc.
> - MongoDB to be used for the actual data of applications / gadgets
>
>3. Important refactoring for better layering and module separation in
>Rave:
>
> - Better separation between "rave-core" and "rave-web" modules - some
> parts are specific to the demo web application and should not be
>present in
> "rave-core". For example: Person and Address classes.
> - Repository interfaces and their usage to be aligned across all Rave
> modules
> - JavaScript changes - the same here: core and demo app parts should be
> Separated
All good points
>
>For now I see the following modules in Rave and their roles:
>
> - Portal Rendering Engine:
> - Page Container - JavaScript libraries to draw the widget
>dashboards
> - Portal Builder - invokes Portal Configuration Repository to build
> the portal pages
> - Widget Container - dialog to draw the actual widget contents and
> toolbars with minimize, maximize, delete buttons
> - Portal Configuration Repository - data model and persistence for
> pages, layouts, regions, widgets etc.
> - Widget Providers Framework - integrations with Shindig and Wookie
> - Demo portal application - current web app bundled with Rave
> Distribution
We are going to start some heavier discussions soon on the dev list
regarding architectural decisions (project organization being one of
them). You are more than welcome to join in, if you like.
>
>Portal Rendering Engine and Portal Configuration Repository will be the
>default integration points for 3rd-party web applications. Demo portal
>parts should be kept separately for not messing with the core sources.
>
>Regards,
>Oleg
>
>
>On Sun, Apr 1, 2012 at 5:34 PM, Ate Douma <at...@douma.nu> wrote:
>
>> 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...
>>
>
>
>> [Oleg] JCR is a brilliant idea. It will enable a data-driven portal UI,
>> which can be built with any JCR-compliant CMS. The only major concern
>>here
>> - performance and scalability of JCR. For enterprise-scale deployments
>>of
>> Rave it may be suitable. But for web-scale deployments of Rave with
>> millions of users and billions of data records it may become a real
>> bottleneck. MongoDB based Repository is a better option for such needs.
I am working on a MongoDB persistence layer that I would like to have in a
working state by June.
>>
>
>
>>
>> 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.
Major, but doable.
>>
>>
>>
>>> 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 :)
>>
>> [Oleg] I've read through this e-mail thread about JCR and HMVC
>suggestions. Both of them are very interesting and correct approaches.
>Especially the view on integrating Spring MVC controllers and other
>frameworks like Lift or Play. It will be also very useful to architect the
>integrations when Rave is a child web app, which is hosted in a parent web
>app - like my case about Lift app. I think that such cases will be more
>frequent than having Rave as a parent web app.
>
>
>
>> 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.
>>
>
> [Oleg] Yes, this is what I'm trying to do now - option #1. And overall
>it looks like the integration effort is not that much tremendous. For
>sure,
>using <iframe> for Gadget Dashboard is not that kind of integration, which
>will cover 100% of requirements. But it will be more than fine for phase
>#1.
>
>
>
>> 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]
>>
Re: Customization options: data model, service layer and UI
Posted by Oleg Puzanov <ol...@gmail.com>.
Hi Ate,
Thanks for your very detailed and positive feedbacks.
I've added some comments inline below. Plus some other ones here.
For now I've come up with the following phase #1 integration plan - around
3 man-weeks of effort:
1. Target approach for UI construction:
- Master Page - rendered by Lift
- Widget Dashboard area - included into Master Page, rendered by Rave,
placed into <iframe>
- Widget Contents (actual app UI) - rendered again by Lift
2. Integration approach:
- Rave is used as a rending engine for Dashboard area only, everything
else is handled by Lift, including "Widget Store" functionality.
- Rave and Lift are running as separate server instances - no such
things as HMVC to present Lift and Rave as a single web application, at
least for now.
- Slightly modified default JPA implementation of Repository interfaces
- Separate PostgreSQL instance to be introduced for Portal UI
configuration data - pages, layouts, regions, widgets etc.
- MongoDB to be used for the actual data of applications / gadgets
3. Important refactoring for better layering and module separation in
Rave:
- Better separation between "rave-core" and "rave-web" modules - some
parts are specific to the demo web application and should not be present in
"rave-core". For example: Person and Address classes.
- Repository interfaces and their usage to be aligned across all Rave
modules
- JavaScript changes - the same here: core and demo app parts should be
separated
For now I see the following modules in Rave and their roles:
- Portal Rendering Engine:
- Page Container - JavaScript libraries to draw the widget dashboards
- Portal Builder - invokes Portal Configuration Repository to build
the portal pages
- Widget Container - dialog to draw the actual widget contents and
toolbars with minimize, maximize, delete buttons
- Portal Configuration Repository - data model and persistence for
pages, layouts, regions, widgets etc.
- Widget Providers Framework - integrations with Shindig and Wookie
- Demo portal application - current web app bundled with Rave
distribution
Portal Rendering Engine and Portal Configuration Repository will be the
default integration points for 3rd-party web applications. Demo portal
parts should be kept separately for not messing with the core sources.
Regards,
Oleg
On Sun, Apr 1, 2012 at 5:34 PM, Ate Douma <at...@douma.nu> wrote:
> 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...
>
> [Oleg] JCR is a brilliant idea. It will enable a data-driven portal UI,
> which can be built with any JCR-compliant CMS. The only major concern here
> - performance and scalability of JCR. For enterprise-scale deployments of
> Rave it may be suitable. But for web-scale deployments of Rave with
> millions of users and billions of data records it may become a real
> bottleneck. MongoDB based Repository is a better option for such needs.
>
>
> 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 :)
>
> [Oleg] I've read through this e-mail thread about JCR and HMVC
suggestions. Both of them are very interesting and correct approaches.
Especially the view on integrating Spring MVC controllers and other
frameworks like Lift or Play. It will be also very useful to architect the
integrations when Rave is a child web app, which is hosted in a parent web
app - like my case about Lift app. I think that such cases will be more
frequent than having Rave as a parent web app.
> 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.
>
[Oleg] Yes, this is what I'm trying to do now - option #1. And overall
it looks like the integration effort is not that much tremendous. For sure,
using <iframe> for Gadget Dashboard is not that kind of integration, which
will cover 100% of requirements. But it will be more than fine for phase
#1.
> 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]
>