Sonette Yzelle asked the following question on the Sakai Developer list.
Hi All,
I am a developer at UNISA. We have to decide what will be the best framework to use in future. We want to become more involved/contribute in Sakai.
We are using struts currently but must decide now if we are going to use RSF, VM, continue using struts or use something else. We don't want to build in unnecessary complication in our codes as we battle to get developers with the right skills and we had 3 resignation in the last 2 months. Questions that game up during our discussion were:
* Will struts be accepted by the Sakai Community?
* What is the general feeling about RSF in the Sakai Community? I found that some hate it and others love it, but I guess you get that with any programming language.
* Can any framework be used in Sakai as long as the tool work?
Do you have any suggestions to help us with our decision please?
-- Sonette
Sonette,
This is a tough question - there are many opinions - this is my opinion:
- Sakai supports a lot of frameworks - so you can choose - as you say - choice is frustrating and wonderful at the same time.
- If you are building something for UNISA only - I would go ahead and use Struts - it will be around for a long time and there is no reason to expect Struts support to become problematic in Sakai
- If you want to build a new tool with wide distribution of a tool across the Sakai community - RSF is the right choice of today - most new work intended for broad distribution I know of is being done in RSF. I would advise against using either JSF or the Jetspeed-inspired Velocity pattern. Neither of these comfortably supports the kinds of web 2.0 kind of stuff that will become increasingly important. In RSF you can gently move between UI stuff and Web 2 things like RSS feeds without hacking things.
- The sdata / widget approach is indeed the promise of the future - but it does not yet work with any shipping version of Sakai and will see its first production use in Cambridge in a few weeks. I suggest letting it settle down in production for a while and see what comes out in Sakai 2.6 to make sure that the future direction for this technology is really worked out. A key to this new approach is that tools end up with a complete redesign - assuming Ajax means that the UI for a complex and powerful tool looks much simpler - so tools end up being built (pretty quickly) from a fresh ground-up perspective. In addition RSF tools will work in the new world in a backwards compatibility mode for a long time.
Of course the SOLO work is all GWT - which looks very awesome - other projects such as OpenSyllabus are using GWT - for now this is interesting and we will have to see how GWT in Sakai shakes out.
So, if you factor all the risks/probabilities - the safest path forward for now is probably Struts for internal UNISA stuff and RSF if you want to build a tool for the rest of us. As you build new capabilities - make sure that you use a service oriented approach and separate your model from your controller/view -because you might end up making a widget to view the data in addition to the RSF tool. If your APIs are clean - making the widget (or GWT version) will be much simpler than if you just mash the presentation and model code together.
Take a look Aaron Zeckowski's GenericDAO code for good API patterns:
https://source.sakaiproject.org/contrib/programmerscafe/genericdao/trunk/
Good APIs lead to good REST interfaces which lead to cool support in SOLO and easy to build widgets.
/Chuck
Posted by csev at July 15, 2008 01:43 PM