站内搜索: 请输入搜索关键词

当前页面: 开发资料首页 → JSP 专题 → JSP 2.1 V JSF 1.2 what's new?

JSP 2.1 V JSF 1.2 what's new?

摘要: JSP 2.1 V JSF 1.2 what's new?

SDN Chat Sessions Transcripts Index

December 7, 2004
Guests: Mark Roth and Roger Kitain
Moderator: Edward Ort (MDR-EdO)

This is a moderated forum.

MDR-EdO: Welcome to today's chat on JavaServer Pages 2.1 technology and JavaServer Faces 1.2 technology. The next release of JSP technology, JSP 2.1, and the next release of JSF technology, JSF 1.2, are designed to improve the alignment of these two technologies in the area of expression language, and to enhance their ease of use. In today's chat, you'll be able to ask questions about these new technology releases and get responses from Mark Roth, the co-specification lead for JSP 2.1, and Roger Kitain, the co-specification lead for JSF 1.2. Our guests are ready, so let's begin. Mark and Roger, can you start by giving us a brief rundown on what's new in JSP 2.1 and JSF 1.2?

Roger Kitain: The JavaServer Faces 1.2 technology release provides a minimal enhancement of the JavaServer Faces 1.1 specification. Its expert group was formed in September 2004. It is not a new feature release. Its primary goal is handling the Faces side of the JSP/Faces alignment issues addressed in the parallel JSR 245 (Java Specification Request 245). Please consult that JSR for details on the primary goal. Following is a list of secondary goals that will be addressed only if the primary goal is reached, and only if the enhancements can be addressed without delaying the schedule.

Mark Roth: The JSP 2.1 specification is being developed under the JCP (Java Community Process) as JSR 245, as mentioned. The expert group was formed this past May; it's been a pleasure working with some of the greatest minds in the industry to bring you the next release of JSP. The focus of JSP 2.1 is on three things: alignment, ease of development, and a more open process. The major news in the Java 2 Platform, Enterprise Edition (J2EE platform) web tier since J2EE 1.4, has been the standardization of a user interface component model for pages that model interactive forms—that is, JavaServer Faces. Due to time-to-market considerations, Faces 1.1 was designed for JSP 1.2 and therefore could not take advantage of newer JSP features. It also meant that JSP could not be changed to meet Faces' needs. This resulted in a number of peculiarities, such as a different expression language syntax and difficulty "interweaving" Faces tags with JSTL tags. The alignment of JSP, the JavaServer Pages Standard Tag Library (JSTL), and Faces is our primary focus in JSP 2.1. The primary theme of the J2EE 5.0 platform as a whole is ease of development. JSP 2.0 and Faces 1.1 have already made large steps towards easing development using the J2EE web tier, but there is always more to do. Finally, in the spirit of JCP 2.6, the JSP and Faces specifications are pioneering a more open process. We now have public issue lists and forums on java.net for our respective specifications, to make it even easier for you to provide feedback!

Webster: When will the specs for these technology releases be available for public review? The JSR page says Public Review: November 2004. Also, because the JSR describes this as "not a new feature JSR," when will JSF be functionally enhanced?

Roger Kitain: The JSF 1.2 (EDR) specs will be available for public review this week. JSF 2.0 will be available after we complete 1.2.

Webster: In an article earlier this year on the O'Reilly site, Hans Bergsten identified a number of anomalies regarding the interplay of JSF and JSP. For example, he showed that the two text strings below will be generated in reverse order (that is, "Some more text" before "Some text"): 

  

  

  Some more text

Will anomalies like this be addressed in the new release?

Roger Kitain: Yes. This is known as the "content interweaving" issue. It will be addressed in JSF 1.2. This problem is centered around when the component tree in JSF is created.

Matt Raible: Is there any chance that web frameworks (like WebWork) could override the default settings for the EL? So ${myForm} can look in areas other than page/request/session/application scope—that is, WebWork's ValueStack.

Mark Roth: Good question, Matt. Actually, JSP 2.1 is not only concerned about supporting Faces. We want also to support other frameworks. The new unified Expression Language (EL) 2.1 API supports the concept of a pluggable VariableResolver (similar to the one that Faces has), which allows you to plug in your own logic for how variables like ${myForm} are resolved. So yes, this will be supported.

dpl: Considering the significant changes that you are proposing in JSF 1.2, would you recommend waiting to start using JSF for new projects?

Roger Kitain: Depending on your timeline or requirements, for starting your new project, you can wait. But nothing, of course prevents you from playing with 1.1.

heath: Currently, there is a gap between "required" messaging needs and the parameters supplied to the default "required" message by javax.faces.component.UIInput. Preferably, there would be a "label" or "description" property added that would be passed to the default message. What is being done to address this issue?

Roger Kitain: Are you talking about error messages? In particular?

staticvoid: Does the alignment of JSF 1.2 and JSP 2.1 mean that, from JSF 1.2 onward, JSF will not work with earlier versions of JSP?

Mark Roth: To clarify, you have the option to use Faces without JSP and that will not change going forward. JSF 1.2 will depend on the unified EL API, which is delivered as part of the J2EE 5.0 platform. So yes, it is true that from JSF 1.2 onward, JSF will not work with earlier versions of JSP. This is no different than, for example, JSP 2.0 not working with versions of Java Servlet earlier than 2.4.

iwaneising: JSF was also meant to have a standard for TAGLIB support in IDEs (like the Sun Java Studio Creator IDE), but there is no standard for design-time support of JSF components. Every IDE has its own extensions. Will JSF 1.2 provide a standard so that you can use any JSF 1.2 component in any IDE in a WYSIWYG manner, like Java Studio Creator's components currently?

Roger Kitain: Our expert group has been involved in design-time support discussions. I think the bulk of this will be addressed in JSF 2.0.

CandidateAdvisor: Will there be any work on better support for the "redirect" pattern? Namely, support to retrieve FacesMessages after a navigation redirect?

Roger Kitain: This may be addressed further on in JSF 1.2, but most probably in 2.0.

RobCo: The forum has a huge percentage of questions and problems going unanswered, and there seems to be little to no participation by major stakeholders on the Sun side. When will that change?

Mark Roth: I assume you're referring to the Java forums. We do periodically scan these forums and answer questions, and we use the questions that appear in these forums to help guide our work on our products. Due to the volume of questions, it is difficult for Sun to answer all questions. For example, the JSP forum alone had 113 messages today so far! While I'd personally love to be able to answer all of them, it's simply not possible. This is why we encourage community participation in the forums.

iwaneising: Currently JSF seems to target only XHTML, although the evangelists—and the web sites as well—state that other presentation media can be used as frontends as well. Will JSF 1.2 get more coverage in that area? The alignment with JSP suggests otherwise.

Roger Kitain: For JSF 1.2, we will address better support for multiple render kits.

heath: Is there a good place to send specification requests? Should we just file a bug report?

Mark Roth: Yes actually, the JSP and Faces expert groups are pioneering a new way to provide feedback into our specifications. We've created public projects on java.net where you can use a public issue tracker, vote for issues, and discuss issues in the forum. We've taken our internal issue lists and made them public there as well. Go to the JavaServer Pages or JaveServer Faces public specification. We look forward to your participation!

chester: There is a common concern about JSF: that it is difficult for the HTML page designer. Will the current or future JSF specification address this?

Roger Kitain: In JSF, a page designer can code the page by hand, which is obviously more work than if you use a tool like the Java Studio Creator IDE. When you use a tool like Java Studio Creator, the process is much easier.

iwaneising: A tool like Java Studio Creator is by no means a tool that will be used by web designers. They will want to stick with Dreamweaver and the like. Will JSF interoperate better with these tools, maybe better and standardized support for Tiles, page templates, or something similar.

Roger Kitain: Interestingly enough, in the early days, we did a prototype that customized Dreamweaver to support JSF. I believe Macromedia has gotten involved in adding JSF support to Dreamweaver.

RobCo: Much has been written about the difficulty of unit-testing JSP because there is no "standalone" compiler. Is there any way for this to be rectified so we could at least get to the level that, say, Velocity is at now, in terms of non-container-based generation?

Mark Roth: Most containers, such as Sun Java System Application Server 8, provide a command-line JSP compiler (see jspc in the bin/ directory).

eduardo: I read about the change from DTD to XML in config files. How will this change affect applications developed on previous versions?

Roger Kitain: It is true that JSF 1.2 has switched over to using XML schema (from DTD). However, DTD is still supported.

iwaneising: Back to the render kits—will the process of developing render kits be described more elaborately, for example, through tutorials? Will there be more than just HTML?

Roger Kitain: I think there need to be more tutorials that describe the process of developing a different render kit. JSF 1.2 has no plans for bundling another render kit. This may happen in JSF 2.0.

Webster: Is the JSTL affected or extended by the new JSP release?

Mark Roth: You will be able to continue to use JSTL 1.1 with JSP 2.1. There are no definitive plans for a new JSTL release for J2EE 5.0 yet, although the JSP Expert Group already has ideas for what we could do if we had one.

dpl: Are there any secondary goals listed on the JSR 252 request that will probably not get included? Have there been any additions?

Roger Kitain: JSR 252 is not meant to be a "new feature" JSR. JSF 2.0 will be more of a "new feature" JSR. We've prioritized a list of items that we plan to address for JSF 1.2.

Guest: In the spirit of EJB3, are there any discussions about marking backing beans with annotations in order to support validation or conversions within the JSF realm?

Mark Roth: Both the JSP and Faces engineering groups have been looking into how we can leverage JDK 5.0 metadata in our respective specifications. So far, the web tier has always trailed the rest of the J2EE platform in terms of the JDK version requirement, however. For example, JSP 2.0 requires JDK 1.3, whereas EJB in the same J2EE release requires JDK 1.4. Therefore, we could not take advantage of JDK 1.4 features in JSP 2.0. Similarly, we probably cannot take advantage of JDK 5.0 features in JSP 2.1 since our minimum version requirement is likely to be JDK 1.4 not JDK 5.0. The reason for this lag is that some web-only containers need to run on platforms that don't have the most recent JDK. We're working to get more feedback from the community to determine if this is still the case for the next release of the web tier or if those platforms have caught up.< /p>

dpl: What is the target final release date for JSF 2.0?

Roger Kitain: That has not been fully determined yet. JSF 2.0 will start as a new JSR shortly after JSF 1.2 has been addressed.

Juneau001: I have heard that there will be an EL that will allow you to communicate with both JSP and JSF within the same page. Is this true? If so, will this work with JSTL?

Mark Roth: Yes, in JSP 2.1 and Faces 1.2, there will be a single unified EL that both specifications share. From the Faces perspective, any EL expressions that appear in a JSP page are parsed by the JSP container. JSTL will use the same unified EL as JSP and Faces use. In fact, so will your own custom tags. So if you have existing tags or new tags, the JSP container will handle the EL for you.

dpl: Are you familiar with the Struts 2 Shale proposal? If so, do you expect future applications to use a JSF and Struts combo or are there plans to evolve J2EE that will render Struts obsolete?

Roger Kitain: I don't think Struts will ever be obsolete, nor are there any plans to make it so. Future applications can certainly use the Struts-Faces integration library.

iwaneising: It is clear that JSF is part of J2EE 5.0, but how will it relate to the Java 2 Platform, Micro Edition (J2ME platform)? Is it SUN's view to have JSF as the defacto front-end framework for client-server based J2ME applications apart from fat clients on mobile-phones, such as web pages accessible through your mobile phone? Or should we stay away from JSF with respect to web-based J2ME stuff and stick with WAP and our WAP tooling?

Roger Kitain: That's an interesting question. For JavaOne, we actually did a render kit for J2ME clients. However, there haven't been any immediate talks about J2ME/JSF.

CandidateAdvisor: Regarding the solution you are preparing for "content interweaving": will component renderers be able to write to the Response's out stream instead of to a separate stream as it is currently? I believe that being able to write to the Response stream may enable better support for third-party tools such as Jakarta Taglibs and SiteMesh.

Mark Roth: Our primary focus has been EL alignment so far, and we're just about to start discussions about solving the content-interweaving problem. It sounds like you have some good feedback on this, and we'd appreciate your participation in our public JSP forum. The content-interweaving problem is primarily a timing issue. The Faces component tree is rendered after the page is executed, so at times it is difficult to ensure that the JSP text gets included in the right spots. Most of the solutions we've been examining so far deal with allowing Faces to access the JSP page programmatically without actually executing the page. More details are likely in the second public release of the spec, but now is the time to make your requirements known in our forums.

iwaneising: How do Struts and Spring relate to JSF 1.2. Currently JSF 1.1 seems to interoperate clumsily with both frameworks.

Roger Kitain: There is a JSF/Spring project out there. I'll have to dig up the information—check the forum in a few days.

Matt Raible: I've found that I often have the same styleClass property on my tags. Does JSF 1.2 allow you to set a default style? Also, is there any chance for allowing a "div" instead of a "table" or "list" for messages. Tables are outdated, and it's especially hard to use that layout since users don't have control over its styleClass property. Of course, I could wrap it in a

but that seems like a workaround.

Roger Kitain: I'm not sure that's on the list for 1.2—it may be. I've now captured the information. I'll check on that.

Guest: Any ideas, syntactically, how JSTL and JSF EL are going to be aligned in terms of client vs. server executions? It seems to be the biggest thing developers battle over on the forums.

Mark Roth: In both JSTL/JSP and Faces, EL expressions are always executed on the server side. Faces does have the concept of storing state on the client, but that is different than actually evaluating expressions on the client. There is, however, the concept of deferred evaluation in Faces, which JSP doesn't have. This is something we fixed in JSP 2.1. The unified EL now allows for deferred evaluation, which can happen either during or after the page has finished executing. In our upcoming Early Draft Review this week, you'll see that in our current solution we preserve the syntax ${expr} for immediate evaluation and #{expr} for deferred evaluation. We chose this for a number of reasons including making Faces developers' lives easier when upgrading their applications. It also makes it clear in a page which expressions will be evaluated immediately and which will be deferred.

heath: If a new render kit is developed, what would they render to?

Roger Kitain: I'm not sure I fully understand your question. Are you asking what new render kit might be included in a future release of JSF?

heath: Someone asked if additional render kits were going to be developed, and you said that there might be one developed for JSF 2.0. If so, what markup it would render to? WAP? XUL?

Roger Kitain: We have not discussed in detail if another render kit would be included in 2.0. It could render to WAP/XUL/ and so on.

Guest: Is there an easy way to access entity beans findAll(), and display them as a data table in JSF?

Roger Kitain: We have not prototyped EJB interfacing with JSF. However, this may be done through the model layer.

CandidateAdvisor: Do you plan to include any items in JSF 1.2 that will provide better support for the much talked about evasive "back button" problems?

Roger Kitain: We have fixed some of the problems with the back button in 1.2 (via our state-saving story). However, there may be some situations where the back button might be a problem.

jhook: EL in JSTL only "reads" expressions. If JSF's EL methods are being deprecated, what will be replacing them? Is it purely a change of "packaging"?

Mark Roth: As you'll see in our EDR release this week, any Faces APIs that deal with JSF ValueBinding and JSF MethodBinding will be deprecated in favor of the unified EL ValueExpression and MethodExpression. In addition, the unified EL now has the concept of deferred evaluation and l-values (setting values instead of just getting values). This allows Faces to rely entirely on the Unified EL instead of having to define its own expression language. Ideally, we would have done this in JSP 2.0, but time-to-market considerations prevented us from having Faces 1.1 rely on JSP 2.0.

Webster: There were a number of performance enhancements made in the JSF 1.1_01 release in September. Will there be any performance enhancements made in the JSF 1.2 release?

Roger Kitain: There have been some performance enhancements with respect to component property descriptor access.

Guest: Continuing to the question on EJB and JSF—does this mean we have to write a managed bean, which calls the entity bean, and set the values in the managed bean, so we can render on the page?

Roger Kitain: That might be one way.

Matt Raible: Will Tapestry-style HTML templates be an option in JSF 1.2 or 2.0? Will the "id" of elements be used as the key, or will something else, like Tapestry's jwcid?

Mark Roth: We'd love to be able to support this in JSP, although I'm personally not clear on all the details of why we can't do this yet today. If you believe there are features missing in JSP 2.0 or 2.1 that still prevent developers from doing tapestry-style HTML templates, please visit our forums and let us know!

Matt Raible: My Tapestry-style HTML templates question was for JSF, not JSP.

Mark Roth: Sorry for the confusion. Actually, if we solve it for JSP 2.1 and if we can solve the content-interweaving problem, then Faces should get it automatically.

jhook: Are you going to continue to use the EL implementation used in the October release of JSF 1.1_01, or is this another rewrite of EL? That also incorporates functions into JSF?

Roger Kitain: The EL engine present in JSF 1.1_01 is not likely to be used in JSF 1.2 RI.

heath: When JSF is included in J2EE 5.0, will we need to manually reference our TLDs since the JSF TLDs will no longer be in our WEB-INF/lib directory?

Mark Roth: In J2EE 5.0 and Faces 1.2, you will continue to use the same taglib imports for Faces in your pages. We're trying to keep the URI the same as for Faces 1.1, but that's not a guarantee. You may need to change it, in the end. But the nice thing is that, because Faces is an integrated part of the platform, you will no longer need to put anything special in WEB-INF/lib. You can expect the tag libraries to be delivered by the container.

MDR-EdO: Well, we've quickly come to the end of our session. I'd like to thank everyone who participated today. I thought we had a nice range of questions. And of course, I'd especially like to thank our guests Mark and Roger for their answers. Look for a transcript of today's session on java.sun.com in a day or two.

Mark Roth: Well, you know it's been a good session when there are more questions than we can handle. Sorry we couldn't get to all your questions during this chat. We'll capture the unanswered questions and keep them in mind. I strongly encourage you to visit our java.net project to continue the discussion about the specifications in our forums and submit issues of your own to our public issue tracker. And, of course, you can always find all the information you need about J2EE at its homepage. Thank you!

Roger Kitain: Thanks for your questions. As Mark said, we'll capture the unanswered questions. Please access us at the JavaServer Faces Technology forum.

MDR-EdO: Moderator signing off. The forum is now unmoderated.

// Popup window function function onRateSubmitHandler() { var w = window.open("","rr","width=800,height=600,status=no,toolbar=no,scrollbars=yes"); w.setTimeout("window.close();", 30000 ); return true; } // End of javascript

↑返回目录
前一篇: JSP 网页制作技巧总结！(java-cn.net)
后一篇: JSP彩色验证码