Integrating Social Apps with Content Driven Sites using Apache Rave and Spring HMVC
- 1. Integrating Social Apps with Content Driven Sites using Apache Rave and Spring HMVC Ate Douma Apache Software Foundation Member committer and PMC member for Apache Rave Platform Architect at open source WCM vendor Hippo ate@apache.org / www.onehippo.org rave.apache.org
- 2. Agenda ● Slightly different scope of this presentation ● Brief introduction to Apache Rave ● Rave features, components and roadmap ● Rave Spring HMVC extension ● Rave JCR back-end and content services ● Demo ● Status and architectural choices
- 3. Scope of this presentation Providing content driven sites with Apache Rave … ● takes more time and work than anticipated ● requires more dynamics than out-of-the-box Spring MVC (as used by Rave) is capable of ● is implemented through a custom Rave extension called Spring Hierarchical MVC (HMVC) ● but for now still is only available as the Rave sandbox module ● will need thorough community evaluation before adoption
- 4. Scope of this presentation Thus: ● I cannot (yet) show truly content driven sites with Rave ● but I will demo a dynamic HMVC based page layout and rendering ● and highlight some architectural choices to be made for further usage and/or integration in Rave
- 5. Brief introduction to Apache Rave ● Started March 2011 in the Apache Incubator ● Graduated as Top Level Project March 2012 ● A lightweight web and social mashup engine ● A highly customizable Java platform for widgets, gadgets and personalized content ● Targets websites and mobile devices for (social) services, intranet and extranet solutions
- 6. Brief introduction to Apache Rave Quick impressions
- 7. Brief introduction to Apache Rave Quick impressions
- 8. Brief introduction to Apache Rave Quick impressions
- 9. Brief introduction to Apache Rave Example: In production at University of Groningen (NL) My University portal, 45K users (student + staff)
- 10. Brief introduction to Apache Rave Example: In production at University of Groningen (NL) My University portal, 45K users (student + staff)
- 11. Rave features, components and roadmap Features ● Skinnable, Twitter Bootstrap UI ● Mobile and desktop view ● User profile page, friends connections ● Page management, personalization, page sharing ● Widget store, widget rating, commenting ● Admin interface for security, widgets, preferences
- 12. Rave features, components and roadmap Features ● Spring Security, JPA, LDAP, OpenID, SAML2, OAuth ● Pluggable persistence model, Apache OpenJPA ● Generalized Rave Widget model, OpenSocial, W3C, … ● Basic inter-widget communication, OpenAJAX Hub ● Spring MVC, Spring MVC, Apache Tiles, REST APIs ● Apache Shindig (OpenSocial), Apache Wookie (W3C Widgets)
- 13. Rave features, components and roadmap Rave components and deployment model
- 14. Rave features, components and roadmap Roadmap and desired features ● Multiple persistence back-ends, MongoDB*, JCR** ● Improved user page model, spaces, security ● More and extended social capabilities ● Enhanced inter-widget communication ● More enhanced front-end customizations ● Dynamic site, page layouts and templates** ● Freemarker templates support** ● Dynamic web content, resources, images, etc.** * Rave mongo branch, go see the “Mongo, its all the Rave” presentation later today, by Matt Franklin ** Rave content-services sandbox, topic of this presentation ☺
- 15. Rave Spring HMVC extension Current front-end render model ('plain' Spring MVC): ● @RequestMapping annotated controller methods note: since Spring 3.1+ the primary supported usage ● ties the URL mapping at compile time to the method ● the mapped method is responsible for the full data model needed for every render element on the page, it needs to be aware of the full page requirements ● Uses Apache Tiles templating to map and wrap the controller method View to a full page layout
- 16. Rave Spring HMVC extension Limitations of standard Spring MVC: ● Controllers cannot be runtime mapped to other URL routes: no runtime route (re)mapping support ● Front-end linking to (other) controllers is 'hard-wired' ● Controllers needs to be 'all knowing' of the page requirements: modifying page structures and layouts may impact changes to many/all controllers ● DRY (Don't Repeat Yourself) is difficult: many controllers duplicate logic (like for menu handling) ● Tiles templates difficult to manage and 'tweak' when you need changes on specific pages only
- 17. Rave Spring HMVC extension Hierarchical MVC: ● HMVC is a known* pattern you’ll find applied by most portal engines and many CMS driven websites ● Frameworks like alloy and kohana (PHP) are based on it, also our Hippo CMS site framework ● It allows building and rendering a page through a set of loosely coupled controllers, instead of only one ● Child controllers only are responsible for their own fragment functionality and may be reused across pages, or even multiple times within the same page ● Pages themselves become reusable building blocks * http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/
- 18. Rave Spring HMVC extension The Rave Spring HMVC extension features: ● external 'route' mapping to wire pages or services ● external hierarchical page structure mapping named fragments to controllers ● page fragment inheritance and merge, custom properties and render/template “viewName” configuration ● mapping definitions in XML or JCR/JSON, auto-reload on changes ● wire HandlerInterceptor(s) to specific routes and/or fragments ● a @Routed controller annotation to distinguish from @Controller ● standard @RequestMapping or extra @Named annotation to map controller methods in a route->page->fragment URL context ● reverse route and name (path) or id based url-mapping support
- 19. Rave Spring HMVC extension Example routes and page fragment definitions: <route path="/" component="/userPage" referenceId="homeRoute"/> <route path="/page/view/{pageId}" component="/userPage" referenceId="pageRoute"/> <route path="/person/{username:.*}" component="/userProfile" referenceId="userProfileRoute"/> <route path="/person/id/{userid:.*}" component="/userProfile"/> <pageFragment name="userProfile" interceptors="userProfile" extends="extended"> <property name="topnav.userProfile">true</property> <pageFragment name="body" viewName="pages/userprofile/page-body"> <pageFragment name="form" viewName="pages/userprofile/page-form" controller="org.apache.rave.portal.web.mvc.controller.UserProfileFormController"/> <pageFragment name="tabs" viewName="layouts/person_profile"/> <pageFragment name="content" viewName="pages/userprofile/page-content"/> </pageFragment> </pageFragment> <pageFragment name="extended" viewName="pages/userpage/page" extends="standard"> <pageFragment name="header" viewName="pages/userpage/page-header"/> </pageFragment> <pageFragment name="standard" viewName="pages/userpage/page"> <pageFragment name="header" viewName="pages/header"/> <pageFragment name="footer" viewName="pages/footer"/> </pageFragment>
- 20. Rave JCR back-end and content services Features: ● extends Rave to dynamically manage and retrieve content, markup, resources, images, etc. ● custom and extendable content domain models mapped to a hierarchical Java Content Repository (JCR), Apache Jackrabbit ● leverages jackrabbit-ocm POJO bean persistence manager ● provides JCR back-end for Rave Spring HMVC configurations ● content bootstrapping and import/export in JSON format ● JSP/Freemarker tags ● optional JCR Web Console for development and administration* * using and extending the open source (Apache License) Hippo JCR Console
- 21. Rave JCR back-end and content services Rave content services components and deployment model
- 22. Demo
- 23. Status and architectural choices Rave Spring HMVC status: ● it already works, but more extensive use-cases most likely will bring up more challenges ● can be used concurrently with 'standard' Spring MVC, allows for gradual migration, but how practical is that? ● current implementation was discussed with and reviewed by Rossen Stoyanchev, Springsource architect for SpringMVC, and he is interested in this solution, but ... ● using and implementing a HMVC based solution is different from what Spring developers are accustomed to, even if on API level there is hardly any difference ● it depends on current Spring MVC behavior, alignment with newer Spring versions is not ensured ● is or should using Spring MVC be the (only) solution?
- 24. Status and architectural choices Rave JCR back-end and content services status: ● (very) basic level of functionality now is available and working ● bringing this to production quality level, and scalable, will require much more effort ● will also need more advanced features build on top (content workflow, versioning, type editing, security, etc.) ● not everyone will need (or want) this, should it remain optional? ● there are other JCR based solutions available who already have these advanced features, albeit not readily usable within the ASF ● should Rave invest in and depend on this heavily, or maybe leave it to the community to integrate on this level themselves?
- 25. Thank you for your attention Apache Rave ● http://rave.apache.org ● http://rave.apache.org/mailing-lists.html ● http://rave.apache.org/source.html ● http://rave.apache.org/downloads.html