RSF is a Java framework designed to simply, replace, and improve on JavaServer Faces. It manages the location and rendering of presentation views, server side and client side state, and handles the HTTP request cycle. RSF is design to work closely with Spring and Hibernate, but doesn't provide data persistance itself.
(What does RSF official stand for?)
Many of these notes are from Antranig Basman's presentation delivered at the Fifth Sakai Conference in Vancouver, Canada.
Some features:
- Built directly on top of Spring. (Is this true or was Spring replaced?)
- Provides XHTML templating. (What specifically is allowed in a template page?)
- Support HTTP GET forms (not just POST forms). (How is this done?)
- 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)
- Free of "model" classes coupling you to the framework
- Focuses on HTML as the basic UI representation - anything is possible.
- Output is GUARANTEED valid XML
- IoC throughout the framework means application fragility does not increase with size, testability, etc.
- Rather than a heap of base-64 encoded Java blobs, bindings are simple collections of Strings.
- Bindings can be manipulated by Javascript and AJAX to create extremely dynamic UIs
- Significant reduction in bean handling.
- Applications are easier to understand and maintain.
- Applications are much more efficient by eliminating server state in sessions.
(How do you define re-usable components?)
The RSF templating engine is called IKAT. It renders pure XML templates annotated only by rsf:id tag.
Everything is based on components. IKAT can handles both looping and branching behaviors, which covers most application operation (switch is missing?).
(What does IKAT stand for?)
(What is a component in this context?)
RSF components have no behavior. They are just a set of fields. These are bean serializable and can be generated and manipulated by non-Java technologies such as XML.
The rsf.id Attribute
The RSF Id can be used in three ways:
- A simple string to denote a component peer (leaf node).
- A container peer indicated by a colon (function call or branch point).
- A static re-write rule indicated by an equal sign (URL re-write or runtime binding).
RSF State Management
By default, RSF doesn't maintain any state.
The component tree and the entire client are deleted at the end of each request.
This miminizes use of server resources without performance impact.
HTTP is stateless and RSF follows this lead.
When state is needed, RSF can easily use Sakai sessions. All state beans should be Java serializable to maximize flexibility. This also makes RSF state to other presentation technologies, includuing non-Java ones.
RSF includes a number of objects based on TokenStateHolder including:
- InMemoryTokenStateHolder
- InHttpSessionTokenStateHolder
- InClusterTokenStateHolder
- InURLPreservationStrategy
- InFormStateHolder
- InCookieStateHolder
These are just some of the examples possible. All of these allow various state staving methods to be implemented. State should be as mobile as possible (what does this mean?)
Ideally, objects should be bean serializable (into XML) rather than just Java serializable. This makes it easier to work with things like AJAX.
RSF Flow
Flow is a conversational state between client and server.
Informal flows can be built up view by view without the need for a central definition file (XML). These are very similar to JSF navigation cases if you leave off the last parameter.
Request Scope Inversion of Control
Request-scope inversion of control within RSF is operated by a lightweight Spring clone, RSAC.
RSAC is file-compatible with Spring (although with slightly reduced functionality), but is nearly 100x faster.
Request scope inversion of control is a crucial part of RSF's flexibility.
Request scope was added to Spring 2.0 at the last moment, but the implementation was deemed to be too slow to be useful in RSF.
(What does RSAC stand for?)
Contrasting JSF and RSF
- Since the RSF ViewProducer is a normal Spring bean, there is no need for the special a Service API which was only needed to inject services conveniently into JSF.
- The iteration logic which was in the JSF bean has now moved into the ViewProducer.
- Instead of copying "representations" of the object into a framework-dependent "magic box" where it is queried later, in RSF you simply render a component on the spot for each Task in the list.
- The loss of the JSP sheds masses of complexity and obscurity - use normal Java code rather than having to package it in "taglibs".
- Applications are now highly portable and have a more flexible UI presentation (skinning).
History
(Who actually worked on RSF?)
(What was the motivation?)