On 8/27/07, Marcus Schmidke <[EMAIL PROTECTED]> wrote: > > I'm in the unlucky situation that I have to give up working with my > favourite Web Framework - Apple's WebObjects - in favor to something that is > more > J2EE-homed and more open source (seems that WO will be this too at some > time, but even then - no chance) and more portal-ready. > Perhaps I will be forced to use JSF, but if I have some good arguments, > perhaps there is a small chance to push some other framework - Tapestry, for > example. > I've experimented a little with JSF and was totally disappointed. The main > things I missed comparing to my previous-millennium-framework were:
I used to do JSF develoment before. JSF 1.2 + Facelet + Spring Web Flow / Seam is bearable, but still way more XML and you are giving away a lot of control how you do things. Some problems are extremely difficult to solve in JSF if the framework doesn't support your use case. "Object oriented developing" means: imagine a list of objects I want to > display in a list box. I want to write a method which extracts a displayable > string, but that's already all. I think it's the framework's problem to > generate HTML-able VALUE-Strings and to convert those strings back to > objects. > My previous millennium framework had absolutely no problem doing this for > me - it simply numbered the elements and the only thing I had to do is to > make sure that the Collection of objects was the same at the beginning of > the next action request. > Frustrated like this I had a look at Tapestry, which was invented in > memory of WebObjects. Most of my JSF-problems seem to have a Tapestry-solution, that's fine. But, > oh no, what is this "ValueEncoder"-thing??? Don't say it is what I'm > afraid of it might be ... Trails (http://trailsframework.org/) would do this and any more things for you. Tapestry gives you a lot of control in how to do things and Trails provides reasonable default in many cases but which you can override and customize to your liking. Kalle
