[luxspes]

Demetrio Filocamo wrote on May 17, 2009 14:41:



You say there are also new articles, it's true (at the end) but why talking about problem of the first JSF versions or problems that you can fix using facelets and seam? (that soon will become a standard too).

Not all JSF problems are fixed by facelets and seam.

So if I want to speak about Java I have to talk about Java 1.0 too? or just about the latest versions?

Just talk about the currently being used version. Talking about JSF 2.0 is like talking about Java 1.7. We are not there yet.

I'm not saying JSF has no problem or it's the best framework (I don't like those kind of discussions) I'm just saying that it's not that bad as you (and others) say...

The problem of JSF is the learning curve but after you learned (and know very well the other related technologies like EJB, JPA, Seam, Facelets, RichFaces or ICEfaces) all is very fast to implement...

Until you realize that your pages weight 100k more and run twice as slow than an the equivalent page built with good old JSP and jQuery :'(

That's my point...

Demetrio

[luxspes]

Robert Burns wrote on May 17, 2009 17:01:


People keep taling in generalisations and claiming that JSF is rubbish and Wicket is the future. Can we have some concrete examples of where Wicket is superior, the only thing I can think of is that some things JSF makes looks like components when they are not (probably comes from old JSP days and jsp:include, et al).

Well, for starters, Wicket has programmatic navigation (as Tapestry and AribaWeb do). Not even Seam or facelets provide programmatic navigation for JSF. AFAIK not even JSF 2.0 (or am I wrong?).

Now, I have read Wicket in Action by Manning and I can't see where Wicket is so superior when you combine JSF/Facelets and Seam. Without Seam I would agree that JSF is a pain in the ass (with all that XML crud in components.xml and faces-config.xml, etc). But Seam solves most of those problems (and you can even use EJB's as form backing beans).

And how about the very intuitive tag handler vs component handlers

From, what I understand Wicket has a very similar pipeline to JSF in request processing (I mean you've got to parse, validate and update the model in every application).

How exactly do you use Seam managed persistence contexts in Wicket, it has no notion of conversation. Should you keep the entity manager open throughout the session? How do EJB's fit into Wicket? I couldn't find an answer to these two questions thereby putting a stop to any attemp to port my application to Wicket.

Well, what is so great about long conversations?. I mean really, they can not even prevent seam-gen from screwing up CRUD. I turns out the only sure way to have conversational behavior is with modal dialogs!. I mean I had hight hopes for conversations, but so far, I have only found temp conversations useful and only because Seam/JSF have no support for programmatic navigation/programmatic data exchange. And do not even get me started on nested conversations...

Don't get me wrong, Wicket makes development more like normal Windows forms programming which is very familiar to more of us. I am not sure I want to program like that any more.

Guess all that ease of use of Windows forms programming is boring for some... but I would really like to be able to focus in business logic and finish stuff fast and easy.. (not always, I do enjoy good puzzles, but sometimes I just want to finish something fast, and so far Seam/JSF have not helped as much as I expected when I started learning how to use it)

Regards.

I do believe Seam (and JSF) have a lot of potential. But I think development should really focus on making everyday tasks consistent, and dead easy to accomplish. I am not saying that special cases shouldn't be hard, but so far it feels like everything I do is an special case...

[vladimir.kovalyuk]

Demetrio Filocamo wrote on May 17 2009 14:41:
I'm not saying JSF has no problem or it's the be
st framework (I don't like those kind of discussions) I'm just saying that it's not that bad as you (and others) say... The problem of JSF is the "learning curve" but after you learned (and know very well the other related technologies like EJB, JPA, Seam, Facelets, RichFaces or ICEfaces) all is very fast to implement...

18 May 2009 16:24 CET Francisco Peredo: Until you realize that your pages weight 100k more and run twice as slow than an the equivalent page built with good old JSP and jQuery :'(

With Richfaces our pages weighted about 300-500k and always re-queried jsf and richfaces resources, which in turn weighted about 600k. Richfaces team planned re-design of some components and Richfaces core. I hope and I wish they succeed. With Wicket we have 50K pages in average and fine-grained control over how browser cache is used. Despite the other performance concerns the size of the page gives us significant performance gain on 1Mbit connections.

[luxspes]

Nicklas Karlsson wrote on May 18, 2009 10:03:


OK. Could you give an example where this lack of vision in JSF regarding contexts and lifecycles of components, expressions, listeners and so on despite the help of a framework (such as Seam) on top has hindered development?

Maybe he is talking about tag handler vs component handlers issue ?.

[vladimir.kovalyuk]

Nicklas,

I don't remember all the weaknesses in JSF. Just a few came to my mind related to UIComponent contract:

1. UIComponent have to work with environment. It should know how to represent their properties, attributes and facets when binding, parsing view, saving/restoring state and so on. Bad design.

2. UIComponent contract extends semantics of java.collections contracts without introducing type-safe interface extension. Bad design.

3. UIComponent is initially designed to be binded, instead of incapsulating. Should be OO inside and provide extensible contract for bindings on top of core OO implementation. Not very good design.

4. All things is done in strings. Names can be overlapped. There is no possibility to consistently perform a refactoring. And who heard about refactoring tool for JSF? Bad design.

Some people in demand on pure java faces. So the topic is hot. That proves that even JSF addicts are in conflict with definitive approach. My opinion is that it is not worth that effort. Wicket handles it nicier.

Concerning context. The phases of request lifecycle, deffered bindings in component tree, the tree itself and user code context are the main contexts of the JSF application. Imagine their state as functions of time. When time increases the phases changes, bindings are evaluated, the tree is modified. User code context usually is the destination side of bindings. But what we see is that there are points when we cant have all the values for all those functions in some points of time. Hence the problem with TagHandler vs Component handler. Hence the problem with new Component approach. In complex cases (read real-world applications) you would have to know how many times the binding is evaluated, in what phases, what bindings are evaluated prior and whether the tree was modified. The same would be partially true for any framework. But only in JSF it is easy to reach by composition of user defined components. It is because the interoperability of those contexts was not taken into account when designing. In OO frameworks you have instruments to overcome and control. Wicket is more thought in case of request lifecycle and contexts. User context is described.

Have you managed to hear what I'm speaking about? Or just write again means nothing, need examples.

From my point of view the problem is too deep. I don't believe JSF guys will address it at all.

The most frustrating thing is that people from the other camps (MS for instance) looking at JSF solution would say Java is stupid and slow. ASP.Net has always been a superior to JSF. Who cares?

[vladimir.kovalyuk]

Francisco,

        Guess all that ease of use of Windows forms programming is boring for some... but I would really like to be able to focus in business logic and finish stuff fast and easy.. (not always, I do enjoy good puzzles, but sometimes I just want to finish something fast, and so far Seam/JSF have not helped as much as I expected when I started learning how to use it)

I do believe Seam (and JSF) have a lot of potential. But I think development should really focus on making everyday tasks consistent, and dead easy to accomplish. I am not saying that special cases shouldn't be hard, but so far it feels like everything I do is an special case...

It is the same for me, Seam/JSF have not helped as much as I expected when I started learning how to use it. Every day we had several especial cases.

Seam is developed to be configured not programmed. The source code is evidence. Like with JSF the declarative approach does not work in complex cases. Only god knows how much time we spent to make URLs behave like in JIRA and work around all the pitfalls. There isn't API at all in some cases.

It is not completely true that you won't think about back-buttoning with Seam conversations. But I find that with Wicket your application do manage to work with back button, browser tabs and windows.