11 May 2007 - RSF version 0.7.1 released!#0.7.1 includes internationalisation upgrades, fine-grained action navigation, and GET form bindings.
21 December 2006 - RSF version 0.7 released!#0.7 includes Multi-file templates, evolvers, composite components and the Universal View Bus.
29 August 2006 - RSF version 0.6.4 released!#0.6.4 includes SpringMVC Integration, BeanGuards, BeanScopes, TLAB, automatic SCR inference.
8 March 2006 - JIRA for RSF goes live#JIRA issue reporting system is now available. Search or report issues at http://www.caret.cam.ac.uk/jira/browse/RSF
1 March 2006 - RSF version 0.6 release#RSF is now stabilising considerably with the 0.6 release. Check the Roadmap and Status pages for a summary of features in this release - most notable is the ORM layer featuring first-class Hibernate support (while keeping it abstracted from user code), and [a pilot] integration with Apache's Cocoon as a Serializer. See Integrations for more information on those.
RSF is now being used in three production projects, with a 4th just starting up, and despite missing some features in the rendering area should be considered a prospect for new development. An exciting recent development is [a pilot] integration with Apache's Cocoon! Given RSF's positioning as an integration platform, this was suitably straightforward, requiring only one class with a few dozen lines of code.
Multi-file templating remains the core missing feature.
10 December 2005 - Austin report#RSF met with a warm reception, overflowing its initial "Birds of a Feather" session into a separate "Q & A" which was very well attended by enthusiastic and interested delegates, despite being scheduled after the end of the conference proper! In general there were signs of widespread dissatisfaction with JSF, and in particular interest amongst the UI team in RSF as a technology for leveraging the "wireframe" HTML UI mockups that the team dealt with, as well as facilitating accessibility work.
5 December 2005 - Demo apps written#several demonstration apps are now written, and there have been considerable structural changes. However, anyone attempting to use RSF for development should be aware of the following major areas of incompletion:
- HTML selection controls are not working.
- Multi-file templating is not yet implemented.
- Error delivery has only been tested for global messages, not yet for field-targetted messages.
28 November 2005 - Gearing up#Since its initial exposure at the Sakai Developers' Meeting here in Cambridge on September 26th, RSF has come on leaps and bounds in its readiness to be actually usable by other developers. Lots of work has been done tidying up its package structure and general self containedness, with a number of significant architectural developments and design decisions:
- The precise role of the contained types within the component tree has been considerably firmed up with the introduction of the UIType scheme. The idea is that component values are an "intermediate" stopping point in between the bean model type and the fully serialised String form as in the HttpRequest.
- Considerable developments on the multi-request front, with the introduction of the StatePreservationStrategy system. This finally resolves the debate summarised in http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=RSVCVersusDeadBeansMRSA between the persistence strategies to be used across multi-requests - you can now use both simultaneously! Use RSVC to persist your Hibernate-exported lazy POJOs, whilst using a more efficient BeanCopy strategy for simpler POJOs you have written yourself.
- A whole flow architecture is now implemented in the FlowLite package. This is a lightweight clone of the basic functionality of SpringWebFlow, although with the extra capability of FreeFlows.
- A serialized form of the component tree has been defined and tested, allowing pure XML views to be constructed for simple cases.
- The component hierarchy around UIBound has been considerably rationalised, with a (nearly) orthogonal choice of options amongst i) the UIType of the control, ii) whether it performs input, iii) whether its value will be fossilized.
- IKAT was converted to a pseudo 2-pass system by splitting off the branch resolution logic in an initial pass. It was proving just too problematic to correctly target error messages via the hierarchical default system in the absence of being able to tell in advance whether a given component was to be rendered or not. There were also numerous other useful use cases for this functionality envisaged, for example when rendering a WAP "do" control, it would be essential to know which of the planned targets actually existed. Hopefully the speed loss would not be too considerable.
- The "fixup" architecture was implemented properly, as well as a properly coherent abstraction of the Forms model - the "0.4" implementation presented in September had considerably upsetting coupling to HTML-style containment forms embedded in the old "UIContainer" container. This class was since split into "UIIKATContainer", and now the modern "UIBranchContainer" and "UISimpleContainer" emphasising the split between the roles of simple containment and branch representation. More work is coming on firming up the exact expectations on renderers of composite "leaf" components which represent UISimpleContainer, such as UILink and UICommand.
- Numerous, numerous upgrades to RSAC aka Summer Lightning to incorporate yet more and more Spring functionality. Now supported are BeanNameAware, BeanFactory, InitializingBean, factory methods, destroy-method, conversion of list-valued properties and other values.. I have drawn the line at constructor arguments, just looks far too nasty.
- Speed trials of RSAC versus genuine Spring to verify that Andy's terrible experience was representative. The >60x speed difference convinced me that the effort in implementing RSAC was not misguided.
- Lots of documentation - including this site!
RSF is now going to get its first proper outing at the Sakai Conference in Austin Texas, December 6th-9th, to see what sort of impressions it makes on the (relatively) general public!
13 October 2005 - Pre-release#the code is in a state of rapid flux as a result of having come into being a short while ago. The core event loop is pretty sound, and has been demonstrated in a quite complex environment (FlowTalk Sakai integration) which has shaken out problems with areas such as form encoding, URL rewriting and the basic bean code.
However, there are a number of core deficits that must be made up before it makes much sense for anyone to try to use the code:
- Not all basic HTML components have been tested (i.e. are not working)
- Error handling and message delivery does not work
- Some deployment issues to ensure the "skeleton app" can be distributed cleanly.