[Building Sakai] UI rendering frameworks in Sakai CLE

[Hedrick Charles]

One of the more pervasive difference between frameworks is how they handle getting data to the UI.

In JSP, JSF and Velocity, loops are done in the JSP. That means your code is split between the producer in Java and the code in the JSP.

Suppose you want to produce a list of numbers and their squares. The typical approach with JSF or Velocity is to pass a list of objects. So your web page looks like

<h:dataTable var="i" value="#{list}">
   <h:column>
      <h:outputText value="#{i.field1}" />
   </h:column>
   <h:column>
      <h:outputText value="#{i.field2}" />
   </h:column>
</h:dataTable>

Then in the java code you have to create a list of the things to be displayed. Now it may be that this list arises naturally in processing, and that there are already appropriate types of objects. However in much of the real code I've looked at, people end up creating special object types for the UI, with of course setters and getters for the fields.

RSF is an exception. You do the loop in the Java code. So it looks something like

<table rsf:id="mylist:">
  <tr><td> <p rsf:id="field1"> </td> <td> <p rsf:id="field2"> </td> </tr>
</table>

The java code then looks like

UIBranchContainer( form, "mylist:");
for (Item i : list) {
   UIOutput(form, "field1", i.getFirst());
   UIOutput(form, "field2", i.getSecond());
}

So the loop is in the Java code, and what is sent to the HTML is simple text strings to be displayed.

Of course it's a matter of taste whether the loop belongs in the Java code or the HTML. Bit I find that it makes more sense in the Java code. Normally in a situation like this you have to produce the list and do something with it in the Java display logic anyway. You end up creating a whole extra layer of code and data structures to communicate between Java and JSF or Velocity that isn't needed in RSF.

I don't know Wicket, so I don't know which approach it takes. The couple of times I've looked at it it has looked similar to RSF, but maybe not.


On Apr 2, 2011, at 12:18:51 PM, Hedrick Charles wrote:

> Lots of people have thoughts. I'm not sure how useful they are.
> 
> I hate JSF. It's great at doing exactly the UI the designers were thinking of, and impossible if you need to diverge.
> 
> Wicket uses secret Java API's. Until recently SCORM caused the JVM to crash. This is extremely scary. I am reluctant to use a technology that has any chance of crashing the JVM.
> 
> My personal preference is RSF. Lesson Builder uses it, and I think has gained from it. However in fairness I have to tell you that the original developer of Lesson Builder disagrees. He fought with it daily. 
> 
> It may well be that the best approach is to use a simple JSP with some of the generic tools such as JSTL. Or Velocity, which seems to have similar strengths and weaknesses.
> 
> However I've never done anything complex that way. My concern is that it would not separate markup from code as clearly as RSF. In Lesson Builder I've needed to do UI reorganizations a couple of times. With RSF that was fairly straightforward. With a JSP it would have been hard. I've had to make changes to UIs in Velocity. I've found it significantly more stressful than in RSF.
> 
> The biggest concern about RSF is its lack of ongoing support. I'm pushing to have the source moved into the Sakai source tree. There are enough people using it in Sakai that I believe if the community becomes responsible for it we can handle the issues that are likely to arise (e.g. the recent addition of support for coeditor, which requires changing an evolved that's in the library). 
> 
> But if I had it to do again I might use simple JSPs for Lesson Builder. We've even considered incrementally converting to that approach. I've verified that we can mix RSF and JSP.
> 
> 
> On Mar 25, 2011, at 12:44:16 PM, Adrian Fish wrote:
> 
>> Hi all,
>> 
>> Putting zealotry aside, does anybody have any thoughts about the 
>> direction the CLE should be taking regarding rendering framework best 
>> practice? I'm talking JSF, RSF, Wicket, Velocity, JSP etc. Does anybody 
>> have any views on what makes a framework good, or bad? HTML purity? 
>> Broad community? Maintainability?
>> 
>> I'm asking because I'm currently learning RSF as some of the software 
>> I'm working on already uses it. In particular I'm working on the Add 
>> Participants tool. It used to be written in Velocity, now it's RSF. So 
>> my final question is: was the switch worth it and if so, why?
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3817 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110402/180468d3/attachment.bin