RSF Programmers - PowerPoint PPT Presentation

1 / 21
About This Presentation
Title:

RSF Programmers

Description:

RSF Programmers Caf and ORM in Sakai with RSF and Hibernate Antranig Basman, CARET, University of Cambridge – PowerPoint PPT presentation

Number of Views:73
Avg rating:3.0/5.0
Slides: 22
Provided by: Bos61
Category:

less

Transcript and Presenter's Notes

Title: RSF Programmers


1
RSF Programmers CaféandORM in Sakai with RSF
and Hibernate
  • Antranig Basman,
  • CARET, University of Cambridge

2
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

3
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
  • Output is GUARANTEED valid XML
  • IoC throughout the framework means application
    fragility does not increase with size,
    testability c.

4
Café TaskList app
  • 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

5
JSF Tasklist App Structure
TaskList.jsp
TaskListServiceImpl.java
TaskListBean.java
TaskListService.java
TaskListManager.java
DataModel
TaskBeanWrapper.java
TaskList.java
6
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.

7
JSF Tasklist App Structure 2
TaskList.jsp
TaskListServiceImpl.java
TaskListBean.java
TaskListService.java
TaskListManager.java
DataModel
TaskBeanWrapper.java
TaskList.java
8
RSF Tasklist App Structure
TaskList.html
TaskListProducer.java
TaskListBean.java
TaskListManager.java
TaskList.java
9
Timeline 1
  • Run the JSF app, and save the HTML it produces
    (take a look at this as TaskList-originalJSF.html)
  • Clean up the HTML (considerably) and annotate
    with rsfid
  • Take faces-config.xml and convert into the
    equivalent Spring declarations
  • Message bundle -gt Spring MessageSource (remember
    to convert . to / in path)
  • TaskListBean.java -gt RSAC requestContext.xml
  • NavigationCase -gt return from TaskListProducer

10
Timeline 2
  • Deal with web.xml
  • Spring listener declaration is unchanged
  • FacesServlet -gt ReasonableSakaiServlet
  • Remove JSF context params
  • Add RSF context param resourceurlbase context
    name
  • Alter Sakai Request Filter mapping to ONLY apply
    to path faces/ (no flexibility here with current
    SakaiRSF but who cares noone should see tool
    URLs anyway)

11
Timeline 3
  • Deal with project.xml
  • A mess, as with all Maven stuff
  • Basically, remove JSF dependencies (JSF and
    commons-X stuff) and add RSF dependencies
    (Spring, CGLib, XPP, ServletUtil and
    PonderUtilCore)
  • NB this project does not use Sakai master project
    but has hard-coded version numbers

12
Timeline 4
  • Write the ViewProducer!
  • In this case, virtually all the logic ended up in
    this file.
  • Made more sense to inject most leaf
    dependencies into the TaskListBean (e.g. siteId)
  • This isnt quite the expected effect, since all
    this code actually has framework dependence
  • But there is much less of it in total, and what
    there is is more straightforward
  • And in truth this actually is view logic. There
    is just a lot less business logic in this app
    than appears at first sight.
  • Talk about LocaleGetter

13
ORM with RSF (OTP style)
  • This app used Hibernate ORM, but did not use the
    RSFHibernate integration library
  • Demonstrates the broad church approach of RSF
  • Basically, if it a Spring bean already, you can
    just use it in RSF without any problems
  • RSF ORM enables us to destroy yet more code from
    this app.

14
RSF Tasklist App Structure with OTP
TaskList.html
TaskListProducer.java
TaskListBean.java
TaskListManager.java
TaskList.java
15
Nearly
  • Actually TaskListManager is serving a dual
    purpose in our refactored RSF app
  • Not only is it the apps interface to its
    storage, it is also Sakais interface to the app
  • This only happens because the app is essentially
    just a CRUD app. For more complex apps these
    interfaces would diverge.
  • RSF only lets you get rid of internal APIs, not
    external ones!
  • So in fact we would need to preserve
    TaskListManager for this app for its external
    function

16
Transit Beans
  • Also, this app does indeed contain one line of
    actual business logic.

if (newtask.getTask() null
newtask.getTask().equals("")) return
"error"
  • This is essentially validation logic. In RSF,
    this belongs in Transit Beans
  • A POJO with a setter, and a getter, which throws
    an exception if value is invalid.
  • Use request-scope IoC to wire it into the setter
    chain

17
How does RSF OTP work?
  • Assigns a unique EL path to each Entity managed
    by ORM
  • This is why returning a Map from the RSF version
    of TaskListManager is the beginning of OTP
  • The EL path for the TaskList with Id of 5 is
    TaskList.5
  • Add new entities with the special id form
    TaskList.new 1
  • Issue special binding type (UIDeletionBinding) to
    unlink or delete an existing entity
  • If the request concludes normally, commit if
    any kind of exception propagates out, rollback

18
OTP result
  • The TaskListBean disappears entirely!!
  • TaskListManager disappears entirely (except for
    external function)
  • Issue We cant do this in RSF right now, since
    there is no deletion binding form for issuing
    multiple deletes
  • Will be fixed in RSF 0.6.4

19
Working example HibernateCookbook
  • Look at javacategory version at
    http//www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page
    HibernateCookBook_4
  • Syntax for a Command link operating a deletion
    binding

UICommand destroy UICommand.make(reciperow,
"recipe-destroy") destroy.parameters.add(
new UIDeletionBinding("Recipe." id ""))
  • Isnt this cool?
  • Brings Java that much closer to the convention
    over configuration scriptaculous scumbag crowd

20
What OTP requires
  • If you have your own SessionFactory, just point
    RSF at it and it will manage all the entities in
    it
  • By default, just define a bean called
    sessionFactory
  • If you are sharing a SessionFactory (e.g. Sakai
    GlobalSessionFactory), need to list the entities
    you want managed
  • You dont have to use Hibernate to use OTP All
    thats required is
  • An AlterationWrapper to enclose the action
    logic which needs to be transactional
  • A set of BeanLocators which expose the entities
    at their root paths

21
Takehome Message
  • There will always need to be external APIs
  • But internally you can do away with boring DAOs
    and action beans, for all basic CRUD
    functionality
  • For some apps, the external API is as wide as the
    data model, so this is not so much benefit
  • OTP is just another RSF design option, the first
    version of the app worked just fine and was
    probably quite enough of an improvement on the
    JSF version.
  • If you are still dealing with Hibernate under the
    covers, you still need to watch out!
Write a Comment
User Comments (0)
About PowerShow.com