portable portlet development with rsf
Post on 22-Feb-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
Portable Portlet Development with RSF
Antranig Basman,CARET, University of Cambridge
Introducing RSF
• What is it, Doctor??
RSF is a Java web programming framework, with roughly the same scope as Sun’s JSF – it takes care of:
• Locating and rendering views• Managing server-side and client-side state• Handling and abstracting the request cycle
It does NOT take care of:• What lies behind your data model (ORM)
Hibernate & co are highly developed solutions to this whichRSF aims to facilitate, not replace.
Why (YET) another web framework?• There are now over two dozen open source Java web
frameworks out there (many probably moribund/defunct)• Would properly need pretty good reason to create another• RSF grew out of work with JSF and preserves all of its
key value points• JSF suffers from numerous architectural, practical and
philosophical problems• Also, JSF is not adapted for lifecycles/environments
typically found in academic institutional development– long maintenance lifetimes– perpetual reskinning/branding– interface aggregation/flexible delivery engines (accessibility vs.
AJAX flashiness, thin/thick clients)
RSF from JSF I
• JSF core value points:– JSF is portable1 – can target the same code at
portlet/servlet environments, – as well as different markup dialects– JSF features a bean line – communication from
view layer to model is only via EL expressions, reflectively evaluating value bindings and method bindings
1 *nearly* - after 3 years and despite both being Sun standards, JSF JSR-168 integration is still incomplete (portal modes &c)
RSF from JSF II• JSF core deficits:
– Neither JSF inputs nor outputs are any kind of XML (by default crummy taglibs as input, half-assed, Javascript-laden HTML as output)
– Does not properly separate logic from presentation (even with Facelets, input “templates” contain iteration and model logic and are NOT safe to give to designers)
– Makes heavyweight use of session state, destroys server efficiency, breaks URL idioms and browser forking
RSF from JSF III• JSF core deficits II
– Lack of support for many core pieces of the browser idiom (bookmarkability, back button, browser forking, POST->GET, GET forms &c &c)
– Fragile request lifecycle (“Phase” system) behaves erratically in presence of exceptions, is generally monolithic and uncontrollable
– IoC integration is at best awkward (JSF-Spring)– Is simply in general a pain to work with – taglibs are
hard to write, framework is highly intrusive, stateful and heavyweight (FacesContext)
– Could go on much longer! (see RSF wiki)
Architectural Snapshots #1: JSF
• Designed on a grand scale• Lots of thought to
architecture, ambitious reach
• Large, complex• Lots of strange noises and
inexplicable phenomena
Haunted House
Quick Recap of RSF Points• The key RSF features are:
– Pure (REALLY pure) HTML templating– Zero server state processing– Built ENTIRELY of a set of Spring contexts,
rather than merely “integrating” with Spring– Request-scope IoC container, RSAC– RSAC leads to straightforward and slick
integration even with extremely peculiar environments (JSR-168, Cocoon, Hibernate, Sakai are all in the bag – IChannel is coming)
• Integrations are always only a few hundred LOC• JSF JSR-168 is thousands
RSF compared to JSF• RSF preserves all the “key value points” of JSF
– Abstract “component tree” isolates you from view technology– EL bindings system isolates the data model from the view layer– Abstract dispatching procedure isolates you from the hosting
environment (Servlets, Portlets, Sakai – IChannel?)• But delivers on all its promises and more
– Free of “model” classes coupling you to the framework– “Speak like a native” approach to HTML – anything is possible– Test your UI in the filesystem, full previewability– Output is GUARANTEED valid XML– IoC throughout the framework means application fragility does
not increase with size, testability &c.
State in RSF
• The key difference for folks coming from JSF is that RSF holds zero server state by default
• Not only the component tree, but also the entire client model are thrown away at the end of every request
• Server resource are precious, and the “time between requests” for a particular user is very large in server terms – why keep around something you could easily regenerate (your app has its own model)?
• A better fit for HTTP which is a stateless protocol. RSF apps are very URL-response, and much more amenable to HTTP tools such as caches, proxies &c
Case Study I : Sakai TaskList App• Part of the Sakai “Programmers’ Cafe” exercise at
Sakai Vancouver Conference June 2006• The simplest app that could be useful• Demonstrates most of the key requirements on a
Sakai app– ORM using standard Sakai SessionFactory (as well as
other approaches, abstracted behind a DAO interface)– Rendering compliant with Sakai Style Guide– Exposing a Sakai-wide service API
• Written in JSF– Easily the most problematic aspect of the whole tool
JSF Tasklist App Structure
TaskList.jsp
TaskListBean.java
DataModel
TaskBeanWrapper.java
TaskList.java
TaskListServiceImpl.java
TaskListService.java TaskListManager.java
Thinking• Looking at the TaskListService API in detail, it becomes clear that
it only really has value *within* the app• This API was created because it is awkward to deliver enough of
the Sakai and other Spring dependencies to a JSF-managed bean• This API and Impl can be destroyed completely in the RSF version• We know that in the RSF version, the view logic in the JSP will be
placed into a ViewProducer, TaskListProducer• The ViewProducer is *already* a Spring-configured bean, so the
dependencies which used to be delivered to TaskListServiceImpl will be transferred onto TaskListProducer
• Since the Producer is normal Java code which has full access to the application state, the “Wrapper” class is also unnecessary.
• The presence of the DataModel in what should be the business layer of the app was an unconditional excrescence.
JSF Tasklist App Structure 2
TaskList.jsp
TaskListBean.java
DataModel
TaskBeanWrapper.java
TaskList.java
TaskListServiceImpl.java
TaskListService.java TaskListManager.java
RSF Tasklist App Structure
TaskListBean.java
TaskList.java
TaskListManager.java
TaskListProducer.javaTaskList.html
It doesn’t stop there
• RSF ORM “idiom” rather than “library”• OTP (= “One True Path”) assigns unique
EL path to each entity of data model• RSF “EL” is slimmed down so much
(only elementary reads/writes permitted) that it is safe to address arbitrarily nasty “POJO” models, even those managed by Hibernate
• Abolition of “DAO”s
RSF Tasklist App Structure with OTP
TaskListBean.java
TaskList.java
TaskListManager.java
TaskListProducer.javaTaskList.html
Result:• A Sakai app free of ANY SAKAI CODE• A Hibernate app free of ANY HIBERNATE CODE• Pure HTML templating makes app effortlessly
reskinnable by anyone armed with a copy of Dreamweaver
• Portable to any environment (where the functionality is relevant) – could become a JSR-168 app with no code changes
• This is impossible with any other framework
NB – could have tried this with interfaces, but this tends to create a fragile design – need to anticipate all design points up front, rather than “abstraction on demand” through request-scope IoC. This approach leads to defining an entire “abstraction platform” covering allcases with “kitchen-sink” type interfaces.
Case Study II: Spring MVC “Step by Step” Product sample
• Thomas Risberg’s very useful walkthrough of a SpringMVC app
• SpringMVC is worthy but modest• Hampered by “Lowest Common Denominator” of
existing view technologies• Spring philosophy of “work what what is there
already, do not implement”• Is NOT portable (Servlet and Portlet packages are
named similarly, but are not interchangeable)
http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html
Architectural Snapshots #2: SpringMVC
• Modest, competent• Works fairly well for everyone• Doesn’t get you very high off the ground (in
terms of abstraction)
Bungalow
1. SpringMVC integration
• The IKAT renderer from RSF has been ported to SpringMVC
• Can be used as “just another SpringMVC rendering technology”, along with Velocity, FreeMarker and JSPs
• Creates some duplication (Controllers/Producers), but highly useful for making reskinnable apps
• “Step by Step” rewritten with drop-in replacement for JSPs, no other code changed
• Resulting app is reskinnable, but still not portable
2. SpringMVC replacement
• Entire app rewritten using RSF• Much code disappears, increased level of abstraction• Preserves ALL non-SpringMVC code with no changes
– Business model/“manager”– DAOs– Spring Validation
• Resulting app *IS* portable to JSR-168, as a result of destroying SpringMVC “Controller” layer
• Not only is the Controller unit testable, but the renderer is as well!! First closed-loop UI testing.
RSF and AJAX• Everyone talks about this, so I’d better• Since RSF preserves complete autonomy on the
client (*pure* HTML templates), all native client-side AJAX libraries integrate naturally – no need for AJAX “components” in the framework
• Lots of success with– Prototype.js– Script.aculo.us– Rico
• RSF renderer is markup agnostic, no problem rendering XML for AJAX tables (Rico), HTML fragments for divs (Ajax.Update) or full pages with embedded AJAX calls.
• Ask Steve Githens (on the RSF forums)
RSF TimelineJuly 2005 “JSFUtil” destroyed
September 2005 RSF 0.5 demonstrated at Developers’ Meeting, Cambridge – UIOutput and UIInput only
December 2005 RSF 0.6 – UIType system stabilised, Flow “Lite”
April 2006 RSF 0.6.1 – Reformed build system, Hibernate support, full XML component serialisability, UISelect – First public release, JIRA, forums
May 2006 RSF 0.6.3 – Complete set of HTML components, non-HTML ContentTypes (XUL, RSS, AJAX), JSR-168
August 2006 RSF 0.6.4 – SpringMVC integration, support for Sakai 2.2, Hibernate 3 (IChannel?). Last 0.6 release
September 2006 RSF 0.7 – Multi-file templates, custom components, “Renderer reform”
Early 2007 RSF 1.0 – General shakedown, acceptance testing, load testing, beginnings of GWT-style integration
The future RSF 2.0 – AutoAJAX, Differential IKAT and the Bean Invalidation Model…. leading to “Snooze”
Acknowledgements
Raymond ChanAndrew Thornton
Dan SheppardIan Boston
and
John Norman
The CARET Team
RSFhttp://www2.caret.cam.ac.uk/rsfwiki
top related