JSF 2.0 Public Review Ballot Starts Tomorrow

In the thread you linked to you wrote: "Bookmarkable URLs, we'll see. Looking doubtful at this point." I will vote NO on JSF 2.0 if you don't include HTTP GET. This should have been one of the top priorities in JSF 2.0. I've emailed the expert group several times asking about this, and emailed some members directly. Nobody will respond. This is not good communication from the JCP, and now it looks like they are dropping the #1 feature JSF developers want! It doesn't matter how great of a job you've done on Ajax and EZComp features if we can't have fundamental basic web framework features like bookmarkable URLs! If JSF 2.0 doesn't have built-in support HTTP GET then I and many others who've been hanging in there waiting for 2.0 will finally give some serious thought about moving to Wicket, Tapestry or Struts 2.

Will JSF 2.0 have same problems with JSTL like JSF 1.X with facelets? http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets

@rdelaplante: Red Hat is contributing resources to work with Ed on getting the bulk of the bookmarkable URL features into 2.0 by drawing on ideas from Seam. We know how important the issue is.

Ryan, you are not the only one watching the bookmarkable URL space. Seam filled it well, and I'll be extremely disappointed if it can' make it into JSF2. If JSF2 cannot prove the pundits wrong (and satisfy us defenders of JSF), then I'll definitely be looking elsewhere. Nuff said.

Thank you Red Hat! The guy who wrote PrettyFaces [1] seems to think that he has done something above and beyond what Seam's boorkmarkable URLs can do. I hope they get him involved, or at least learn from his project. I know URL rewriting/pretty URLs was not planned, but I hope that makes it in as part of the HTTP GET support. http://ocpsoft.com/uncategorized/jsf-get-bookmarkable-and-pretty-urls/

Lot of community investment has gone into improving JSF and bring spec to JSF 2 level. I hope it comes out with flying colors. Bookmarkable URL, Easy Component Creation, AJAX, PDL etc are very critical. Skinning is also something which we should address in JSF 2.1(subsequent release after stable JSF 2 release). Now once we are done with JSF 2 we should quickly start discussing on JSF 3 (JSF1.2.x - to JSF 2 took years), may be something like JAVAFX widgets integrations, JAVA FX charts integration more client side (JAVA Script SandBox), better IDE support , better performace, etc.. JSF 2 seems to be very promising and future should be brighter.

Mr. Delaplante, The issue for this is https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=485. I've posted your latest comment to this blog in that issue.

Validators are restrained to components that implements EditableValueHolder, so with components like HtmlDataTable the validators can not function, when I need validate the length of the collection that HtmlDataTable contains with a validator I can not validate that collection because validators are only valid in EditableValueHolder Components and HtmlDataTable is not an EditableValueHolder.

Please improve tooling support for facelet tag libraries. Facelet tag libraries that use the library-class element, make it very hard for tools to support arbitrary namespaces. com.sun.facelets.tag.TagLibrary provides no iteration methods. We can't even tell what namespace it supports. An examination of tool support to make certain tools can minimally obtain namespaces, elements, and attributes, whenever possible, would be most appreciated. I'm referring to https://facelets.dev.java.net/nonav/docs/dev/docbook.html#taglib-create, since I did not see any specifics in the public review.

@edburns: Excellent, thank you. I'm really looking forward to JSF 2.0 and HTTP GET support. Hopefully with pretty URLs/url rewriting like in Seam and PrettyFaces too. BTW, the Rich Faces team says that they are working on a cleaned up JSF 2.0 version: http://www.jboss.com/?module=bb&op=viewtopic&t=146232

I too hope JSF 2 migration that will start after Majorra JSF 2 stable release, will be well documented and less painful or easy. JBoss Rich Faces branch relase for JSF 2 will be an important milestone for JSF 2 adoption.

Why is there a public review vote before the spec reaches final draft, and no public vote of the final draft? Public review vote ends in a couple of days and it doesn't have HTTP GET. HTTP GET isn't even on your chart, despite someone telling me that Red Hat has added extra resources to get it done. Is what they said true? That will affect my vote. Can they really start and finish that in the three weeks before proposed final draft? I would like to see someone from the EG blog about what changes are being done to state saving.

I just re-read this blog entry and realized that despite being called a PUBLIC review ballot, the public cannot vote. The vote is for JCP Executive Committee members only. I hope the they are reading the comments in this post and are aware of the HTTP GET issue.

It appears that nothing has been done about multi field validation: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1 (yes ticket #1, something we've wanted forever.) Multi component validation should also be addressed in JSF 2.0. Today the only way to achieve this is to use the EditableValueHolder's getSubmittedValue method to retrieve the value of some other component while in the validator of the first component, but the javadoc warns against using that method: "This method should only be used by the encodeBegin() and/or encodeEnd() methods of this component, or its corresponding Renderer." Performing multi field validation in the action is not a viable option because it can only output FacesMessages. Actions don't have the same effect on specific components that Validators do. Wicket has had support for multi component validation since 2006: http://cwiki.apache.org/WICKET/validating-related-fields.html http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wic... http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wic... Tapestry also seems to be capable of multi-field validation: "Next, all the fields inside the form are activated to pull values out of the incoming request, validate them and (if valid) store the changes. After the fields have done their processing, the Form emits a "validate" event. This is a chance to perform cross-form validation that can't be described declaratively. Next, the Form determines if there have been any validation errors. If there have been, then the submission is considered a failure, and a "failure" event is emitted. If there have been no validation errors, then a "success" event is emitted." http://tapestry.apache.org/tapestry5/guide/validation.html

HTTP GET is a MUST!! This can't be left out. This has been a complaint from day one of JSF. Years more cannot go by before this is included. I fear more people turning away from JSF if this is not part of 2.0.

RD> It appears that nothing has been done about multi field validation: RD> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1 RD> (yes ticket #1, something we've wanted forever.) Multi component RD> validation should also be addressed in JSF 2.0. Today the only way RD> to achieve this is to use the EditableValueHolder's RD> getSubmittedValue method to retrieve the value of some other RD> component while in the validator of the first component, but the RD> javadoc warns against using that method: Hello, we're looking to JSR-303 BeanValidation to help with this. In fact, Emmanuel Bernard, has been doing an excellent job and we're fully ready to include it in JSF 2.0 when the Java EE 6 platform group approves it for inclusion. Ed

>>>>> On Fri, 09 Jan 2009 16:49:23 -0800, foo@bar.com said: RM> Please improve tooling support for facelet tag libraries. Facelet RM> tag libraries that use the library-class element, make it very hard RM> for tools to support arbitrary RM> namespaces. com.sun.facelets.tag.TagLibrary provides no iteration RM> methods. We can't even tell what namespace it supports. An RM> examination of tool support to make certain tools can minimally RM> obtain namespaces, elements, and attributes, whenever possible, RM> would be most appreciated. Hello Rod, thanks for the comment. We're certainly wanting it to be toolable. The combination of the composite component metadata (section 3.6.2.1) and JSR-276-Metadata, would be plenty for tools. Please make your desire for JSR-276 Metada known to its EG. jsr-276-comments@jcp.org.

Ed> Hello, we're looking to JSR-303 BeanValidation to help with this. In Ed> fact, Emmanuel Bernard, has been doing an excellent job and we're fully Ed> ready to include it in JSF 2.0 when the Java EE 6 platform group Ed> approves it for inclusion. In http://forum.hibernate.org/viewtopic.php?p=2403001#2403001 Emmanuel Bernard appears to say the opposite. Apparently we're not getting multi-component validation. Note that JSR-303 does support it, but JSF doesn't seem to integrate with it (yet?).

John Reynolds wrote about an interesting idea [1] where JSF's h:form tag can have validator(s) attached to it, like any other input component. The form could validate the submitted values of any combination of components using business rules, and throw a ValidatorException when there is a problem. That is how Wicket does "business form"/multi component validation [2] and it seems that this would be a simple addition to JSF 2.0 or 2.1. JSR-303 BeanValidation is definitely welcome, but I think this idea is just as important for JSF. [1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by... [2] http://cwiki.apache.org/WICKET/validating-related-fields.html

>>>>> On Thu, 22 Jan 2009 07:54:28 -0800, foo@bar.com said: RD> John Reynolds wrote about an interesting idea [1] where JSF's h:form RD> tag can have validator(s) attached to it, like any other input RD> component. The form could validate the submitted values of any RD> combination of components using business rules, and throw a RD> ValidatorException when there is a problem. That is how Wicket does RD> "business form"/multi component validation [2] and it seems that RD> this would be a simple addition to JSF 2.0 or 2.1. JSR-303 RD> BeanValidation is definitely welcome, but I think this idea is just RD> as important for JSF. We have a simple but sufficient solution to this for JSF 2.0. It's been checked in. RD> [1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by... RD> [2] http://cwiki.apache.org/WICKET/validating-related-fields.html

This is excellent. I'm glad to see multi-form validation, while it was "possible" that didn't make things "easy." Being easy, and being correct/accurate is what drives adoption :)

We are working on HTTP get and I think you'll like what we come up with. Ed

If you're not using Seam (, e.g.) then I would say that HTTP GET would be very necessary. Also, Seam has a @Validator annotation which makes business validations much easier to handle. I'm talking about use cases which require a db read to determine if the value entered in a inputText is already in a table or not (dynamically onblur and also onsubmit of the form). In these cases, with Seam apps, you can't use a custom Hibernate Validator b/c it exists outside of the Seam lifecycle and will not necessarily behave as expected and reliably. There is a valueChangeListener attribute in JSF but I'm not sure if it works as well as the Seam Validator.

In my previous post, the Validator annotation is applied to a SFSB public method, not an entity class property or method (as is generally done with Hibernate Validator).