Re: What's the latest thinking of the best two or threewebdevelopment languages/environ...

Aaron Bartell skrev den 07-08-2008 18:47:

I like a lot of the features in JSF and I dislike a lot of the features in
JSF.

The thing that I really enjoy is the seamless nature of mapping screen
variables back to the controller, and mapping events from the page back to
Java methods - very easy.

I agree, that is the strong selling point of JSF.
My likes for JSF are additionally:

The simple way to dereference information in EL's. "foobar.a.b.c" automatically uses "getA" in the foobar bean, finds B in the map gotten by getA and something else I cannot remember now for C. The rendered="no" attribute to conditionally render stuff without iffing.The #{....} syntax to render a variable. The datatable tag to iterate over a collection/resultset. The posibility to avoid JSP and HTML-tags completely if you write properly and use CSS. The ability to mix tag libs if they are written properly.

My dislikes are:

Annoyances were: Cannot pass parameters in function calls in EL (got around that). No intuitive way to pass information from one request bean to another (in the next request) - Tomahawk has an updateActionListener which can do that. The myfaces compiler caches the data structure so changing the JSP does not update the parsed data structure (got around that with an id-attribute).

Lack of proper STANDARD debug tools (in the JSF). Often I'd like to simply see all the objects in the session scope etc.




I wrote all my JSF manually without using a GUI. Somehow my way of working does not fit into the world of GUI-designers.

The things I learned to dislike are when I needed to step slightly out of
the box that JSF created. For example, I dislike the limitations of not
being able to embed other HTML without tags like <dataTable> without using
the <verbatim> tag. I also grew tired of having to update the

This should work properly if you use facelets instead of JSP as the rendering engine. I have not tried.

faces-config.xml file with any and all navigation and/or controller/bean

I ended up simply saying that there was a rule for each page with a wildcard for "came-from" with the same name as the page. Then you can just say "success.jsp" and you go there.

The Rails approach with convention over configuration is much nicer. Hopefully the Sun folks will learn the lesson.

definition. Another is the inability (at least they don't recommend it) of
including JSP tags beside the JSF tags. This wouldn't be an issue if the
JSF tags covered everything the JSP tags had. At the time I couldn't find a
simple <jsp:if> tag in the JSF spec and that made things real fun for
business logic from controller to screen.

What is it you need to do? Can the rendered attribute do that?

You can create booleans to determine if a given portion should be displayed at all. These can be used in the rendered attribute. Same thing with columns in a datatable.

Could you list some of your likes and dislikes of JSF and maybe I can be
swayed back into the fold, and maybe it will also give Dave some good food
for thought.

I don't want particularly to sway you anywhere. I am just trying to represent what I have found and which things influenced my decision to go with JSF. There were two major reasons - one being that I started out in Struts which is a major pain so JSF was much nicer, and the mere existance of a Sun specification (which I simply think cannot be underestimated in value). I think the thoroughness of the Java Language Specification and the Sun approach to backward compatability has given developers confidence in the platform and the longitivity of the solution.

As midframe developers we understand better than most that code live forever. The question is how much pain we have to suffer to allow it to :)