Ed Burns's Blog

JavaServer Faces 1.2 and JavaServer Pages 2.1 Public Review Specifications available

I'm pleased to announce the availability of the Public Review revisions of the next release of the JavaServer^TM Faces and Pages specifications. The Faces spec may be downloaded from <http://www.jcp.org/en/jsr/detail?id=252> and the Pages spec may be downloaded from <http://www.jcp.org/en/jsr/detail?id=245> We really want feedback! Please use our Forum to share your thoughts on the specs. Or you may send feedback to the comments alias for Faces or JSP (jsr-252-comments@jcp.org and jsr-245-comments@jcp.org respectively) .

In this entry, I link to a comprehensive high level outline of the changes to the spec since the 1.1 release of the Faces spec. I've decided include changes present in the December Early Draft Release as well as the current release for completeness. Keep in mind this is a high level outline, for details, I encourage you to read the relevant sections of the spec itself.

Before we get to the outline, here is a brief summary of the main changes:

• Unified EL

  The expression language used in Faces, which was inspired by the expression language used in JSTL and JSP, has been generalized and extracted into its own top level javax.el package. The EL is agnostic of the technology hosting it, such as JSP or Faces, and is intended to be generally useful in the same way one can use OGNL in a variety of applications. Faces now has deprecated its internal EL in favor of using the Unified EL.

• New Tree Creation and Content Interweaving Model for Faces applications that use JSP

  While it is perfectly acceptable to use Faces without using JSP, many people find their productivity increases when using these two technologies together. Unfortunately, as amply documented by Hans Bergsten in his article at onjava.com, there were some integration cases that didn't work as expected. By changing the specification of the implementation of the Faces ViewHandler for JSP, as well as changing the JSP custom tag base class used by all Faces component tags, these problems have all been resolved.

• Integration with JSTL

  Another long standing problem was in using JSTL's <c:forEach> tag to contain Faces input components. Because JSP has no notion of a postback, it was not possible to apply the values correctly to the nested input components on postback. By introducing some new concepts into the EL, it is now possible to fully use <c:forEach> with any kind of Faces component. This will require a new release of JSTL, which will also be present in J2EE 5, along with Faces and JSP.

• Back Button issues and Multi Frame or Multi Window Faces Apps

  Due to a deficiency in the State Management API using Faces in Multi Frame or Multi Window applications presented some problems. The browser back button also could cause application state to become confused. These problems have now been fixed.

• Associating a message with a particular component in the page.

  Previous revisions of the spec didn't allow for dynamically including the label of a component in an error message for that component. New spec features now allow for this to happen.

The golden question, of course, where's the implementation? It's all implemented, but the implementation of the Faces spec is only partially available, due to the unavailability of a public implementation of the JSP 2.1 spec. There are two reasons for this.

1. We heavily leverage the new, Unified EL, that is a separate spec document but, for convenience, is being delivered under the JSP 2.1 spec. So, while using the Unified EL does introduce a dependency on JSP 2.1, there is nothing stopping someone from implementing the EL spec outside of JSP.

2. In order to fix the Tree Creation and Content Interweaving problems (which are inherent to the old way of using Faces and JSP together, and therefore already implicitly dependent on JSP), as well as using <c:forEach> with Faces input components (and therefore implicitly dependent on JSTL), we had to make changes to the JSP spec, which are being delivered as part of JSP 2.1

The parts that are unavailable are those parts that a user would encounter only when using Faces and JSP together. The parts that are available are those parts that a user would encounter whether they use Faces with JSP or not. Features that are unavailable at this time are listed in gray, available features are listed in non-gray text. Available features are present in the latest release of the official Faces implementation on java.net which continues to run on J2EE 1.3 containers. Note that the content in section IV is mostly available.

Now, the outline of changes is available here.

Comments

• Ed,
  In general these changes look great, but I have a some concerns regarding the tight coupling between JSF and JSP (Statements like:"only partially available, due to the unavailability of a public implementation of the JSP 2.1 spec." make me cringe).
  It looks like this release will correct many of the "problems" that Hans Bergstan pointed out when using JSF and JSP together, but I'd hate to see the JSP support preclude all other methods for using JSF components.

  I know that there is talk of developing "Tapestry -like views" support by David Geary on his blog... but I am very curious if you've heard much interest for pursuing this from the expert group in general. What do you think?

  -- John

  Posted by: johnreynolds on April 15, 2005 at 06:57 AM

• JR> In general these changes look great, but I have a some concerns
  JR> regarding the tight coupling between JSF and JSP (Statements
  JR> like:"only partially available, due to the unavailability of a
  JR> public implementation of the JSP 2.1 spec." make me cringe).

  From the beginning, JSF has required that a JSP implementation be
  present in the container. Since J2EE 1.2, this has been true. JSF has
  never required that an application use JSP at all, simply that it
  exist in the container. This hasn't changed.

  I've updated the blog entry to allay your fears. Please let me know if
  your fears are indeed allayed!

  JR> It looks like this release will correct many of the "problems" that Hans
  JR> Bergstan pointed out when using JSF and JSP together, but I'd hate
  JR> to see the JSP support preclude all other methods for using JSF
  JR> components.

  As mentioned above, it won't.

  JR> I know that there is talk of developing "Tapestry -like views"
  JR> support by David Geary on his blog... but I am very curious if
  JR> you've heard much interest for pursuing this from the expert group
  JR> in general. What do you think? -- John

  There is interest in the EG, and I'm interested in it personally, but we
  won't be specifying that sort of thing for 1.2.
  

  Posted by: edburns on April 15, 2005 at 07:42 AM

• Oops, that got mangled. I'll preview this time.

  JR> In general these changes look great, but I have a some concerns
  JR> regarding the tight coupling between JSF and JSP (Statements
  JR> like:"only partially available, due to the unavailability of a
  JR> public implementation of the JSP 2.1 spec." make me cringe).

  From the beginning, JSF has required that a JSP implementation be
  present in the container. Since J2EE 1.2, this has been true. JSF has
  never required that an application use JSP at all, simply that it
  exist in the container. This hasn't changed.

  I've updated the blog entry to allay your fears. Please let me know if
  your fears are indeed allayed!

  JR> It looks like this release will correct many of the "problems" that Hans
  JR> Bergstan pointed out when using JSF and JSP together, but I'd hate
  JR> to see the JSP support preclude all other methods for using JSF
  JR> components.

  As mentioned above, it won't.

  JR> I know that there is talk of developing "Tapestry -like views"
  JR> support by David Geary on his blog... but I am very curious if
  JR> you've heard much interest for pursuing this from the expert group
  JR> in general. What do you think? -- John

  There is interest in the EG, and I'm interested in it personally, but we
  won't be specifying that sort of thing for 1.2.

  Posted by: edburns on April 15, 2005 at 07:43 AM

• Now that the spec is somewhat finalized, I will be working on extending view support into something very similar to Tapestry that doesn't require JSP *use*.

  I know a few other frameworks allow 'components' to be defined in other documents, just grabbing the body of the document, except in this case, it will return a component tree that can be pulled/reused in any other document. I know I gruffed in the EG about UIComponent's use of Expressions in order to represent properties/attributes instead of literal values, but it might possibly open the door to higher performance gains in other view technologies-- this weekend the fun begins....

  Jacob (JSR 252 EG & EL Alignment)

  Posted by: jhook on April 15, 2005 at 08:36 AM

• Thanks Ed... my fears are allayed.

  On another note, I added a comment on the JSF forum about "form-level validation"... What I am looking for is a standard point for applying validations after all of the individual components have been validated.
  The standard practice now seems to rely on adding a hidden component after all the visible components, and adding a custom validator to that component. I have problems with that approach (it seems like a kludge, and it will break if someone inadvertently "moves" the hidden component).

  Is it possible that you could address this in 1.2, or is it too big a change?

  Thanks,
  --John

  Posted by: johnreynolds on April 15, 2005 at 08:41 AM

• Jacob,Go for it! (a Tapestry-like JSF option)You'll be my hero ;-)--John

  Posted by: johnreynolds on April 15, 2005 at 08:44 AM

• Shale has a works in progress attempt at JSF Tapestry support. The solution is more geared for constructing a component subtree using something other than JSP. The component is called Clay.

  Currently there are three options:
  1) XML tiles like meta component definitions that support inheritance
  2) Runtime construction for a postback to the managed bean.
  3) Tapestry like support where a html jsfid attribute binds to the XML component definitions.

  http://issues.apache.org/bugzilla/show_bug.cgi?id=33752

  Gary

  Posted by: gvanmatre on April 15, 2005 at 11:45 AM

• I believe Hans Bergen is wrong.
  I don't know if I like JSF yet.. but JSP 2.0 is in ways a superior technology than Tapestry (at least from what I've seen). What? Yes, that is what I said.
  The main justification for my unpopular view is that JSP 2.0 allows you to naturally reuse portions of your UI code. Find a fragment too repetetive? Cut & paste in into a tag file and now raise your level of abstraction. In tapestry you have to break out the Java editor and code.
  That is similar to Tag libraries (JSP 1.x) where you were forced to code something that is naturally expressable in JSP (with JSTL help) as Java in a .java file.
  If Java followed such a philosophy the only method you'd be able to define would be main() and it would force you to define other methods with JNI. End result: people wouldn't use nearly enough reuse... just everything would get dumped in the main().
  Reusable view descriptions should be easy to define. JSP 2.0 has this, and ASP.Net has it too.

  Posted by: dog on April 15, 2005 at 12:43 PM

• Dog,
  Let's agree to disagree on Tapestry (I have found it fairly easy to create reusable view descriptions), but I think you missed the real point in Han's article. There are some pretty bizare side effects when mixing JSP tags with JSF tags. The good news is that most of those issues are being addressed in the new JSF and JSP specs. This is great news for the folks like you who want to use JSF with JSP.
  

  Posted by: johnreynolds on April 15, 2005 at 02:08 PM

• I've been developing with JSF since it came out, and quickly realised that using JSPs with JSF was very unproductive.
  I took Hans Bergstan's code as an inspiration and modified it so that each view is defined in an xml file, which end up looking like:

  <?xml version="1.0" encoding="UTF-8"?>
  <html>
  <head>
  <title>test</title>
  
  </head>
  <body>
  <div style="#{test.redStyle}" >div with red style</div>
  <form >
  inputText:
  <inputText value="#{test.inputTextValue}" required="true" id="inputText" />
  </form>
  </body>
  </html>

  
  I parse the view file using sax, and create a jsf component for each tag based on a mapping file. This includes the html tags, which I create generic components for. This has the huge advantage of being able to put EL expressions in html attributes, and also to be able to modify the whole component tree programmatically.

  This library has since been used in a commercial production web app, and proved very productive. We would consider donating it to a project like shale or myFaces it if it could become part of a default standard for using views like this.
  We have also been experimenting with creating jsf components that implement AJAX using json-rpc. Very powerul stuff.

  Anybody interested can contact me via email at
  jon dot nermut at dytech dot com dot au

  Jon Nermut, Dytech Solutions

  Posted by: jnermut on April 17, 2005 at 05:58 PM

• Still no bookmarking support though. Sad.

  Posted by: prophecy on July 31, 2005 at 06:34 PM

• Yeah, I know, it's terrible, isn't it? The problem is the matter of server side state. Please see the issue for details.

  https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72

  Please vote for it!

  Ed (JSR-252 spec co-lead)

  Posted by: edburns on August 01, 2005 at 06:37 AM

• Seeing as JSF 1.2 targets Jave EE 5, are you now 'allowed' to use Jave SE 4 features (I hear you are always supposed to be one version behind)? Specifically generics?

  I was hopeful that my managed beans, while they must of course have a parameterless constructor, could be generified? This is because many of my managed beans seem to do exactly the same things (load, save, delete, etc.) but to different types of objects.

  I would like to be able to do, for example:

  <managed-bean>
  <managed-bean-class>com.me.MyBean<User></managed-bean-class>
  </managed-bean>

  <managed-bean>
  <managed-bean-class>com.me.MyBean<Order></managed-bean-class>
  </managed-bean>

  Is this possible?

  Posted by: kenrodd on August 14, 2005 at 07:38 PM

• Hello Ken,

  Keep in mind that the point of the managed-bean-class elements is only
  to tell the runtime what to pass to Class.forName() to load the class.
  You can certainly generify your managed beans as much as you like, but
  only in the .java source files themselves. Because the generics
  information is generally a compile only time feature you'll be ok.

  Ed

  Posted by: edburns on August 15, 2005 at 08:50 AM

• Ed,

  I have a alignment problem in my JSF data-table. It's happening occasionally.
  Example, I have 3 fields in my data-table, First-Name,Last-Name and SSN.
  Occasionally, one of the values gets overlapped with the next cell.Meaning, a part of FirstName gets displayed in LastName and part of LastName in SSN.

  I tired with iFrames in JSF and also by having fixed width for each cell. still, the problem persists.

  Is it got to do something with JSF?
  Please help.

  Thanks

  Posted by: viewcleared on July 11, 2006 at 01:30 AM

This work is licensed under a Creative Commons License.