RSF version 0.7.2 has been released. RSF promotes minimal and clean designs - in contrast to the majority of current Java frameworks which proliferate with increasingly complex schemes for managing stateful components, RSF cuts through the issue by promoting and facilitating zero server state designs. This brings web development more in line with the web - as well as making fewer demands on server resources, it arguably delivers apps which users find more idiomatic and intuitive. Other features since RSF's previous announcement at 0.6.1 include UVB (the "Universal View Bus") - a slimline DWR-like RESTful web service automatically derived from your webapp structure, and extensions to its rendering model allowing any section of markup to become a candidate for reuse. Going forwards, RSF is rapidly tracking the developments towards Spring Web Flow's 2.0 release, with its integration up to the mark for compatibility with the latest milestones of SWF 2.0M1 and Spring 2.1M3. RSF's focus on markup purity and type-safety for view resolution is a perfect complement to SWF's positioning as a universal application controller and state management engine. RSF is actively working with the Fluid Project to produce a maximally reusable and accessible set of client-side components that work - for everyone. The forthcoming 0.7.3 release of RSF will focus on automatic client-side validation and improvements in portalization, in advance of the major revision 0.8, where RSF APIs will be brought in line with their 1.0 release versions by alignment with Spring 2.x and Java 1.5-level features. Release notes and changelist are available on the RSF wiki. A large set of sample applications and guides are available to help programmers get started. Discussion and support are available on the forums and the mailing lists.

RSF version 0.7.2 has been released. RSF promotes minimal and clean designs - in contrast to the majority of current Java frameworks which proliferate with increasingly complex schemes for managing stateful components, RSF cuts through the issue by promoting and facilitating zero server state designs. This brings web development more in line with the web - as well as making fewer demands on server resources, it arguably delivers apps which users find more idiomatic and intuitive.

Hmm... most prototype Java web apps have minimal and/or clean designs on par with the examples I saw at the RSF site. The RSF Demo to me is visually comparable with MyFaces-Tomahawk so I don't agree that an app based on the RSF widget set would be any more idiomatic and intuitive than an app based on, say, Tomahawk. Also, I'm not sure that 'complex schemes for managing stateful components' is really a big problem with most of the leading available JSF implementations. To me, component state tends to be as simple as deciding whether you want client or server-side state and setting a parameter in web.xml for JSF state saving. As for 'clean' designs, I think the Richfaces JSF component library is pretty darn clean. The popup calendar is kind of nice...

RSF isn't really about the widget set, although of course we are working to make this as good as possible. It is really about focusing on designer-led markup. If you take a look at the format for RSF templates, you can see that it is as close as possible to XHTML, with just a single attribute added. This reduces the risk of fragility in round-tripping between designers and developers to the minimum, and gives designers the power to "reskin" markup down to the last tag and attribute. If Richfaces or some other component library works for your requirements, that is great. RSF targets a sector of applications where users and designers are much more picky about markup and need greater control. In a JSF design, even with Richfaces, control over markup ends at the "taglib" boundary, where it passes over to developers. It's really a matter of where the control is held, rather than the suitability of any particular solution/widget set.

RSF isn't really about the widget set, although of course we are working to make this as good as possible.

I see; the 'Server Faces' in RSF threw me off because in general, component vendors often put Faces in their product name so that one immediately thinks of JSF as well. Is RSF not a component set for JavaServer Faces?

It is really about focusing on designer-led markup. If you take a look at the format for RSF templates, you can see that it is as close as possible to XHTML, with just a single attribute added.

Are you familiar with Facelets? If so, are you familiar with the jsfc attribute? Facelets makes it possible to create XHTML-centric UI; one can simply use form elements from the HTML-form element palette if UI simplicity and cleanliness is desired in the rendered markup. More about jsfc here

That's right - RSF is unrelated to JSF technologically, although you could call it a kind of distant conceptual ancestor. RSF is a self-contained technology that occupies a lot of the same functional space as JSF. Yes, I am familiar with Facelets - and although it is a considerable improvement on previous schemes for drawing up JSF views, it still suffers from the basic problem that I referred to that "control ends at the taglib boundary". Whilst Facelets gives control over the overall setting of a view, it gives no control over the markup for what is traditionally called "components". You can get an idea of the kind of difference I'm referring to by looking over our conversion of the Spring Web Flow "Hotel Booking Sample", which was originally a Facelets-JSF-SWF app, which was converted to an RSF-SWF app. http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=HotelBookingSWFSample To be clear, we're aiming at cleanliness at *both* ends - not just in the rendered markup but also in the source template. This should be something that can serve as a "common document" to designers and developers, and as such should be free of developer-domain specific information such as EL paths and component names.

Yes, I am familiar with Facelets - and although it is a considerable improvement on previous schemes for drawing up JSF views, it still suffers from the basic problem that I referred to that "control ends at the taglib boundary". Whilst Facelets gives control over the overall setting of a view, it gives no control over the markup for what is traditionally called "components". You can get an idea of the kind of difference I'm referring to by looking over our conversion of the Spring Web Flow "Hotel Booking Sample", which was originally a Facelets-JSF-SWF app, which was converted to an RSF-SWF app.

I see the *small* difference. I can consider it an improvement respects to Facelets. Instead there is a big enhancement respects previewability. Instead of writing a new framework, why not improve Facelets? Let's concentrate efforts. JSF pluggability gives the opportunity to improve the base framework a lot. For example you can implement a new view technology (if you consider Facelets too different) to emulate the RSF one. About the "Application transparency" I don't see why should be easier then JSF data model. Anyway I think it is absolutely possible to import such programmaing model into JSF, re-implementing some of its handlers (maybe only the view handler).

Yes, what you say is quite inviting. Actually we made strong attempts during the early design phases of RSF to stick within the JSF model - RSF actually had the first 6 months of its life as a set of utility libraries "JSFUtil" whose purpose was to make it easier to work with JSF. These were actually quite similar in functionality to what is now called "Facelets", only with the notable difference of the improvement in navigation transparency provided through the (now RSF) "ViewParameters" class. This issue is now being attacked in JSF through an independent route by Spring Web Flow. Unfortunately after painful soul-searching, we were forced to conclude that the benefits we desired really could not be delivered with the JSF framework, despite the considerable community advantages that could be gained by this route :) Yes, the example as posted does not show *too many* differences to Facelets, but it is worth concentrating on the differences that are visible even in this simple example. i) Although the "jsfc" tag mentioned by a previous poster allows us to restore some measure of previewability, the tag you place it on is essentially a "fake" - its actual name and any attributes attached to it will be overwritten by the taglib renderer. Thus it is not actually either a *faithful* preview, nor a useful point of control to the designer. Therefore we see that in this example the designer is obliged to provide superfluous

IMHO, designer-friendliness is a crap shoot. HTML is a crappy markup for describing many of the assets we need to use to build our UIs, so consequently, we build higher level constructs. In the process, we decompose flat, designer-oriented HTML pages into easier to maintain components. A separate issue of debate is where you handle markupjava integration. There's pro's and con's for either route and it comes down to personal preference. RSF looks more like Wicket than JSF code. The example linked uses 'HotelUtil', what's hiding in there?

IMHO, designer-friendliness is a crap shoot.

I agree with this statement. In practice, web designers tend to be out of the picture once static mock-ups are complete. After that, the developer takes over and works on integrating live functionality into the mock-ups. It's rare to see a dynamic web UI evolve as the result of both the web designer and the developer simultaneously working on the same artifacts. Thus, concentrating on designer-friendliness in a templating or presentation technology possibly has extremely low return on a project. I think Facelets is good enough in this regards; on several real projects, we have had designers use a Facelet-boiler-plate XHTML file, created by a developer, for all UI design work. Facelets worked well in Dreamweaver, etc...

I'm another RSF developer (just as a quick disclaimer). I understand that for a lot of enterprise-ish needs, the above tends to be true. I don't think HTML is a particularly great layout schema, but unfortunately it's what we're stuck with. Because we work on stuff for higher education and academia, our User Designers are super specific about what they want things to look like. They're not java programmers, but they are pretty hip and know what they want their CSS and tag layouts to be. We've used JSPs, Veloctiy, JSF and things of the such in the past, and in general our Designers were pretty unhappy. Because the templating rules in RSF are so simple, our team of a few designers, spread across a few universities, now actually do their work on our RSF projects on the same files, same Subversion, etc as the developers. It's been a great bonding experience, and they don't have to sit around twiddling their thumbs anymore waiting for us to do things. Anyways, HTML isn't always great, and isn't always perhaps important to be in the hands of designers through the entire development cycle, but for the sort of (sometimes artsy) things we're trying to build, it works out pretty swell. The usability of our applications has really started to improve since we started keeping designers in the entire development cycle, too.

It's rare to see a dynamic web UI evolve as the result of both the web designer and the developer simultaneously working on the same artifacts. Thus, concentrating on designer-friendliness in a templating or presentation technology possibly has extremely low return on a project.

What you say is quite true. RSF is essentially about extending the reach of Java webapp technology towards more "low-return" projects. If you are perhaps one of the more typical users of this site, you design your apps "ballistically", they are deployed once, in one place, for an essentially homogeneous customer base, and aside from minor tweaks and maintenance over their lifetime, that is essentially it. For applications and a customer base like that, the economics are in favour of one of the more traditional technologies like Wicket or Facelets. RSF applications typically are deployed many times, in many different guises, and serve an essentially very heterogeneous user base, and need to be easily reskinned on the drop of a hat, and have to work without the benefit of a commercial toolchain and support. This is what the industry typically terms "low-return" projects, and this is the application sector which RSF targets.

It's rare to see a dynamic web UI evolve as the result of both the web designer and the developer simultaneously working on the same artifacts. Thus, concentrating on designer-friendliness in a templating or presentation technology possibly has extremely low return on a project.

What you say is quite true. RSF is essentially about extending the reach of Java webapp technology towards more "low-return" projects. [...]

For me, it's not really so much about the ultimate size or "return" of the project as about the size of the project's iterations. What Bradley Smith describes sounds like a traditional waterfall approach to project management. What I'm after is agile development with small fast-moving cross-functional teams. In that situation, direct designer access to the code base is desirable. (And yes, the situation certainly assumes a fair amount of tech savvy in both the UI designer and the Java programmer.) In a cross-functional team, I found vanilla JSF 1.1 to be overly intrusive and even downright hobbling when compared to plain JSP 2, but, to be fair, I haven't yet tried Facelets + JSF 1.2 on a real-world project.

IMHO, designer-friendliness is a crap shoot.

I very much dislike the HTML that designers deliver, it is far from what can be called "clean". Designers should now their CSS and everything will be fine.

IMHO, designer-friendliness is a crap shoot.

I very much dislike the HTML that designers deliver, it is far from what can be called "clean". Designers should now their CSS and everything will be fine.

If I may say, this symptomises exactly the kind of developer-centric bunker mentality that has led to the development of the mostly deficient array of current view technologies. Designers as well as developers will vary in the level of excellence they bring to their craft, and if you were to look at a lot of the Java code that is pumped out by the "average developer" I'm sure you would also consider it highly deficient. The issue historically is that developers of web frameworks have not been prepared to respect the competence that designers might be capable of bringing to the process, or even that design is indeed a valid discipline in its own right. It's hardly a surprise, if the popular impression is that "design ends with CSS".

IMHO, designer-friendliness is a crap shoot.

I very much dislike the HTML that designers deliver, it is far from what can be called "clean". Designers should now their CSS and everything will be fine.

If I may say, this symptomises exactly the kind of developer-centric bunker mentality that has led to the development of the mostly deficient array of current view technologies. Designers as well as developers will vary in the level of excellence they bring to their craft, and if you were to look at a lot of the Java code that is pumped out by the "average developer" I'm sure you would also consider it highly deficient.

The issue historically is that developers of web frameworks have not been prepared to respect the competence that designers might be capable of bringing to the process, or even that design is indeed a valid discipline in its own right. It's hardly a surprise, if the popular impression is that "design ends with CSS".

You may say so but my opinion is that designers are designers and HTML is code-ish. How on earth can I make a decent component that is also easy extendable while I let everybody fool around with my markup? I am telling you CSS covers 95% of the needs but unfortunally most dont know how powerfull it actually is.

You may say so but my opinion is that designers are designers and HTML is code-ish. How on earth can I make a decent component that is also easy extendable while I let everybody fool around with my markup? I am telling you CSS covers 95% of the needs but unfortunally most dont know how powerfull it actually is.

I agree the power of CSS is generally underestimated. But just as a sampler, here are some things which you can't do with CSS. i) Re-ordering. CSS can easily change layouts from horizontal to vertical and v.v. but cannot for example change the relative ordering of elements. ii) Table layout. Switching a layout from tr, td to div/span + CSS pr v.v. is prohibitive in other frameworks. If you have a table "widget", you are stuck with the markup it produces, which is generally locked up in developer-land. If you don't like its tags/strategy, tough - go write yourself a new widget. With RSF/IKAT, this sort of change can be achieved just in HTML. Nested tables/repetition also no problem since it is a unified system throughout. And to answer this point specifically - "How on earth can I make a decent component that is also easy extendable while I let everybody fool around with my markup" - actually that is *precisely* what we want! The web abounds with clever "widgets" that have their markup/DHTML behaviour precisely the way *one* developer decided. We will shortly be moving on to generalised tree controls, but as an early output from the Fluid Project take a look at the "Reordering control" http://wiki.fluidproject.org/display/fluid/Reorderer-Lightbox+Separation+of+Concerns This packages the functionality of allowing "reorderability" through some variety of modes, both keyboard + mouse, but without compromising accessibility, but *at the same time* allowing full control over the markup which is output, which is specified in plain HTML like everything else. In JSF/Facelets, you would need to write a new widget/taglib for every different kind of "payload" for this control.

IMHO, designer-friendliness is a crap shoot.

I very much dislike the HTML that designers deliver, it is far from what can be called "clean". Designers should now their CSS and everything will be fine.

That is exactly why I value the approach implemented by Tapestry(used, love it), Wicket(use now), and RSF (not used) - they allow reusing whatever HTML has been given and more - they allow put the burden of maintaining the HTML on the shoulders of original producers, sweeeet:) I could advice them to use CSS or do decent job, but in the end developers are not affected by HTML quality that much.

Let's concentrate efforts. For God's sake yes. Channel these improvements towards Facelets and the ongoing JSR.

Noooooooo! Spring noooooooo! This is killing Java! How many XML files will I have to edit in order to make a Hello World?

Noooooooo! Spring noooooooo! This is killing Java!

Smart things such as Spring hardly kill a technology: stupidity could, instead.

Smart things such as Spring hardly kill a technology: stupidity could, instead.

Oh tell me, smart one, what Spring is good for? Spring is a framework for everything and for nothing, trying to mimic features from dynamic languages. Have you ever wondered why Rails is such an hype? If you are a developer you need to understand what your current environment is good for, otherwise it is the opposite of smart.

Hi Guys, Congratulations on the RSF release. I just have a quick question: can IKAT be used on its own as a templating engine? PS if this is already properly documented somewhere, feel free to post a link and I'll do my homework. Many thanks. Freddy

Hi Guys,

Congratulations on the RSF release. I just have a quick question: can IKAT be used on its own as a templating engine?

PS if this is already properly documented somewhere, feel free to post a link and I'll do my homework.

Many thanks.

Freddy

Yes, IKAT can be used as a standalone renderer. Probably the most convenient packaging for this usage style is the SpringMVC integration where IKAT templating can be dropped in as a direct replacement for JSP/Velocity et. al. You can see a worked example here: http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=SpringMVCStep Cheers.

Yes, IKAT can be used as a standalone renderer. Probably the most convenient packaging for this usage style is the SpringMVC integration where IKAT templating can be dropped in as a direct replacement for JSP/Velocity et. al. You can see a worked example here:
http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=SpringMVCStep

Cheers.

Thanks Antranig for your reply and the link to the step-by-step example. Very interesting stuff. Cheers, Freddy

Aaron or Steven, what ("competitive") advantages do you see over Wicket or Tapestry approaches?

Aaron or Steven, what ("competitive") advantages do you see over Wicket or Tapestry approaches?

I think each of these technologies fulfills a different need despite the shared concepts. It is hard to answer a question like this because I would not bother working on RSF if I thought there were better options out there. I assume the Wicket and Tapestry teams feel the same way. I am not going to get into a "who is best" argument because those are colossal wastes of time but if you want my opinion then here it is. A shop which is heavily invested in JSF development is likely to be more effective in the short term with Tapestry than with RSF or Wicket. A shop which has little familiarity with Spring and JSF would make faster progress with Wicket than RSF and Tapestry. I feel that a development group with a strong set of designers and good experience using Spring is going to be most efficient and productive with something like RSF compared with Tapestry and even Wicket. That's just my opinion though and not meant to detract from the strengths of any other project. There are many factors to consider when choosing a view technology and there is no right answer and no silver bullet. I personally recommend a "don't believe the hype" and "try before you buy" approach to choosing technologies. Give them all a try and pick the one you prefer.

I personally recommend a "don't believe the hype" and "try before you buy" approach to choosing technologies. Give them all a try and pick the one you prefer.

+1

+1, but I'd add also that once you've made a choice, it can become a trap to prefer the one you picked. technologies change.