Public review drafts of the JSF 1.2 and JSP 2.1 specifications, which focus on interoperablity, bug fixes, and refinements, are now available.

New features and changes to JSF include:

• Unified expression language (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 "Improving JSF by Dumping JSP", 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

Some of the changes for JSP 2.1 from 2.0 include:

• JspApplicationContext - This class contains context information specific to JSP containers, and allows pluggable expression language resolvers
• Expression Language changes - A new package for expression language classes was created, and the old package was deprecated. Many new features were added to the expression language.
• Tag library changes - New rules and capabilities for the use of tag files and libraries were added.
• trimWhiteSpaces directive - A JSP page can now be directed to remove whitespaces after JSP directives that do not have any other content after them.

As a public review, the JSR groups are asking for feedback. If the JSRs do not have a feature you think they need, please let them know.

I have more detail on the spec changes available in my blog at http://weblogs.java.net/blog/edburns/archive/2005/04/javaserver_face_1.html
including an outline of the changes that show which features are
publicalli available in the reference implementation now, and which are
not yet available.

Ed

JSP improvements are welcome.

JSF still has some way to go before I'd invest time and money in it.

JSF will get there - it's got a great spec team. They are just moving too slowly... and not going for that final push that will make JSF great.



PJ Murray

CodeFutures Software

Java Code Generation for Data Persistence

I think one of the big obstacles to JSF development is debug information. It is very difficult to understand why some jsf exceptions have occurred. Many of the exception messages don't help the developer and some of them leads to wrong directions.

Let me give an example,

java.lang.IllegalArgumentException: Conversion Error setting value ''{0}'' for ''{1}''.
at com.sun.faces.util.Util.getSelectItems(Util.java:628)
at com.sun.faces.renderkit.html_basic.MenuRenderer.getOptionNumber(MenuRenderer.java:488)

The above exception tells that this is an error related to conversion. But the actual error was a typing error of JSF expression:

        <h:selectOneMenu styleClass="p" id="priorityCmb" value="#{entry.priority}" >
            <f:selectItems value="#{entry.priorityItems"/>
        </h:selectOneMenu>

'}' is forgotten above.

Mert

I think one of the big obstacles to JSF development is debug information. It is very difficult to understand why some jsf exceptions have occurred.

Tapestry provides sophisticated built-in exception reporting and line precise error reporting for years.
So does Java itself, but some people never look for inspirations :( Not-Invented-Here-Syndrome is way too widespread

I think one of the big obstacles to JSF development is debug information. It is very difficult to understand why some jsf exceptions have occurred.

Tapestry provides sophisticated built-in exception reporting and line precise error reporting for years.So does Java itself, but some people never look for inspirations :( Not-Invented-Here-Syndrome is way too widespread

Some of us from the EG group are working on a technology for JSF that is very much like Tapestry and serves the specific purpose of building Component trees without a ServletContainer (much like Velocity). I know that the Struts Shale group has a committer who's been working on a separate XML view definition, along with a few others.

-- Jacob

I think one of the big obstacles to JSF development is debug information. It is very difficult to understand why some jsf exceptions have occurred.

Tapestry provides sophisticated built-in exception reporting and line precise error reporting for years.So does Java itself, but some people never look for inspirations :( Not-Invented-Here-Syndrome is way too widespread

<sarcasm> Yes, let's stop immediately each and every web framework development right now, because there is no way they will ever reach Tapestry, even less surpass it.
</sarcasm>
Not mentioning that JSF is an stardardization effort, so it is up to Tapestry's and other similar web frameworks' communities and vendors to decide if they should be JSF compliant or not, based on the pros and cons of such conformance. Meanwhile brand new JSF spec compliant _implementations_ are popping up (RI, MyFaces), which will of course have a long way before catching up with other web frameworks, because, obviously, they are much more recent than the rest. Should they be qualified as NIH syndrome, or just players in this standardization effort? I think the right question should be: should there be any standardization in this specific area, or should the industry go all by itself? I vote for standardization.

Regards,
Henrique Steckelberg

<sarcasm> Yes, let's stop immediately each and every web framework development right now, because there is no way they will ever reach Tapestry, even less surpass it.</sarcasm>Not mentioning that JSF is an stardardization effort, so it is up to Tapestry's and other similar web frameworks' communities and vendors to decide if they should be JSF compliant or not, based on the pros and cons of such conformance. I vote for standardization.Regards,Henrique Steckelberg

No sarcasm: If a framework does not have a goal of substantially improving and surpassing an established FW then yes, it should be abandoned.

See: I am all for standardization too :)

No sarcasm: If a framework does not have a goal of substantially improving and surpassing an established FW then yes, it should be abandoned. See: I am all for standardization too :)

It would be dumb to not have such a goal, and I doubt everyone involved with JSF would think otherwise. IMO JSF allows for both things, due to its flexibility: have an implementation at least as complete and easy as Tapestry, and still be spec compliant. Just give time for vendors and open-source community.

Regards,
Henrique Steckelberg

No sarcasm: If a framework does not have a goal of substantially improving and surpassing an established FW then yes, it should be abandoned. See: I am all for standardization too :)

It would be dumb to not have such a goal,

Really? Then why there are so many projects doing the same thing and they do not cooperate?

and I doubt everyone involved with JSF would think otherwise.

Would not question that :)

IMO JSF allows for both things, due to its flexibility: have an implementation at least as complete and easy as Tapestry, and still be spec compliant. Just give time for vendors and open-source community.Regards,Henrique Steckelberg

That is the problem. JSF would be fine 4 years ago, but today it feels like anachronism. Because:
- it does not provide very convenient development environment and simply fuels vendors, which will come up with things to sell for sure;
- it does not look very attractive from architectural perspective because it misses IT turn back to basics: do UI work on clients (RIA, XUL are mostly anemic successors to X-Windows architecture);

Yes, JSF and Tapestry are identical from architectural perspective ( like Ford Model-T and Lamborghini), but evil is hidden in details (as usual). JSF tries to be too abstract to be convenient as opposed to Tapestry, which is not ideal but seems like well-balanced approach to do browser-oriented applications.

would be dumb to not have such a goal,

Really? Then why there are so many projects doing the same thing and they do not cooperate?

Why not? Can't each of them seek this goal separately? Or should there be only one framework to "rule them all"? Besides, having a standard will foster cooperation.

IMO JSF allows for both things, due to its flexibility: have an implementation at least as complete and easy as Tapestry, and still be spec compliant. Just give time for vendors and open-source community.Regards,Henrique Steckelberg

That is the problem. JSF would be fine 4 years ago, but today it feels like anachronism. Because:- it does not provide very convenient development environment and simply fuels vendors, which will come up with things to sell for sure;

I think you are confusing JSF _specification_ with JSF _implementations_ (plural!). JSF specification does not dictate any development environment. For an _implementation_ to work or be usable, it will depend on how it is implemented.

- it does not look very attractive from architectural perspective because it misses IT turn back to basics: do UI work on clients (RIA, XUL are mostly anemic successors to X-Windows architecture);

JSF Spec does not dictate any specific UI. Take Shale for example, they have planning an AJAX UI for their JSF implementation. There are people evaluating the integration of JSF with Thinlet (a XUL framework). That is the flexibility I am talking about.

Yes, JSF and Tapestry are identical from architectural perspective ( like Ford Model-T and Lamborghini), but evil is hidden in details (as usual). JSF tries to be too abstract to be convenient as opposed to Tapestry, which is not ideal but seems like well-balanced approach to do browser-oriented applications.

JSF (again, the specification) HAS to be abstract, in order to be flexible. Just because one specific implementation focuses on web ui, it doesn't mean other implementations should be restricted to that too. And JSF is not flexible just regarding the rendering aspect, you can plug in almost every aspect of it. This flexibility is exactly what will allow JSF _implementations_ to surpass other web frameworks. It is not a guarantee, but at least the door is there to be opened.

I see people often confuse JSF specification with JSF implementations. Take this into account when evaluating JSF.

Regards,
Henrique Steckelberg

Just to show where one JSF implementation (Shale) is heading:
http://www.jroller.com/page/dgeary/20050321

This is not a guarantee that JSF will ever dominate web framework space, it just shows what JSF Specification allows for when it comes to implementation.

Regards,
Henrique Steckelberg

Just to show where one JSF implementation (Shale) is heading:http://www.jroller.com/page/dgeary/20050321This is not a guarantee that JSF will ever dominate web framework space, it just shows what JSF Specification allows for when it comes to implementation.Regards,Henrique Steckelberg

There is a very interesting passage in the blog entry:
#Do I use Tapestry? Heck no. I have a mortgage to pay.#

I think it supports idea that JSF is driven by vendor's desire to build something to be able to sell it. Vendors are not interested in something that simply works but support everything that requires significant efforts to rebuild.

This is where people should say NO.

I think it supports idea that JSF is driven by vendor's desire to build something to be able to sell it.

<sarcasm>
Ok, let's dump this whole standardization effort because we found in someone's blog one little phrase which proves JSF is an evil plot set by vendors to take our money away.
</sarcasm>

Konstantin, it looks like all you are looking for is any excuse to blindly bash JSF for whatever reason at all. I quit this useless discussion.

BTW, I like conspiracy theories too. :)

I think one of the big obstacles to JSF development is debug information. It is very difficult to understand why some jsf exceptions have occurred. Many of the exception messages don't help the developer and some of them leads to wrong directions. Let me give an example,java.lang.IllegalArgumentException: Conversion Error setting value ''{0}'' for ''{1}''. at com.sun.faces.util.Util.getSelectItems(Util.java:628) at com.sun.faces.renderkit.html_basic.MenuRenderer.getOptionNumber(MenuRenderer.java:488)The above exception tells that this is an error related to conversion. But the actual error was a typing error of JSF expression:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<h:selectOneMenu styleClass="p" id="priorityCmb" value="#{entry.priority}" >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<f:selectItems value="#{entry.priorityItems"/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</h:selectOneMenu>'}' is forgotten above.Mert

That is a good catch, I will check with the RI group to see if they are handling the problem. With the new Spec, "#{entry.priorityItems" would throw an exception at tree creation time as an invalid expression, which would avoid the later, cryptic error message during conversion.

-- Jacob

Oh, great news!

I've just curious - are there some plans for support of declarative definition of UI in JSF (or some third-part project) instead of using JSP with custom tags?

Of course, JSF is "tool-oriented" technology, but I'm really doubt that in current state JSF is ready for development of large "functional" web sites that contains huge amount of forms and user interactions - i.e data processing oriented sites like this one; (while it seems JSF could be fine for some smaller solutions).

Pure declarative definition of UI, say, XML based, IMHO, is just vital key for simplicity and easy of support - some time ago we've created our own web development platform based on Struts that used such approach and now I just can’t imagine to code UI manually in JSP.

I suppose that support of mechanism similar to XUL for building user interface could be really brilliant feature of JSF.

Just my 2 cents.

-------------
Sincerely,
Andrew Sazonov
http://www.softamis.biz - High quality custom Java and Web Solutions.

Oh, great news!I've just curious - are there some plans for support of declarative definition of UI in JSF (or some third-part project) instead of using JSP with custom tags?

...

Pure declarative definition of UI, say, XML based, IMHO, is just vital key for simplicity and easy of support - some time ago we've created our own web development platform based on Struts that used such approach and now I just can’t imagine to code UI manually in JSP.I suppose that support of mechanism similar to XUL for building user interface could be really brilliant feature of JSF. Just my 2 cents.

Sincerely, Andrew Sazonov

JSF at its foundation, doesn't make any committments to any view technology. Sun and other vendors, such as Oracle, do see worth in leveraging existing JSP knowledge/solutions for JSF with custom tags. So while this release does take steps towards making JSF and JSP more compatible, JSF is still view agnostic.

Hans Bergsten's JSF article does describe UIComponent declaration in a seperate XML file (with working code)-- this would include both visual components and validation concerns, separate from the HTML.

So what you've requested is more than do-able, just that the primary focus of development in the EG is to simplify JSP/JSF integration for J2EE 5 while leaving the door wide open for integrating JSF with other technologies and standards.

-- Jacob (JSR 252 EG)

Its something we are very interested in as well - for magnolia http://www.magnolia.info - we use a declarative approach to build user interface dialogs.

From what we have learned now, this can be done in JSF, which we currently consider as the basis for future versions of magnolia.

And, with shale, it seems there is already work under way to build on top of JSF an even better framework, so that sounds interesting as well.

Anyways, congrats to the improvements. How long until these things can be seen in production?

Cheers
Boris

Thank you for your note. Yes, this is brilliant article (yet his approach is quite limited) and it highlights exactly the same issues with JSP I personally don't like in JSF.

Yes, you are correct - it's great to have JSF agnostic from UI and clean separation between UI and business logic is very important. Of course, using other technology rather than JSP will hurt lots of software vendors that support JSP only in their IDE.

The question is rather slightly different - is general JSF page lifecycle flexible enough to be truly view-agnostic?

We've tried to combine JSF and XML based definition of UI.
However, we found that is was complicated to make such integration in conformance with general lifecycle supported by JSF without changing lifecycle.

Actually, we wanted to add quite specific functionality that probably is important for just special class of Web application - ones that are data oriented. That functionality included very dynamic assembling of web pages based set of predefined fragments and dynamic graphs of POJO obtained from application server (something like Tiles on steroids) and one of goals that we tried to achieve was very clean separation between UI designers and developers (actually, designers were not familiar with Java and JSP).

Please note that we've tried to do this using Sun RI that is based on previous version of JSF so currently situation may be changed - I'm very interested to check it in new specification.

By the way, is it planned to add some support of layout managers (similar to ones used in Swing) to JSF? We've implemented our own ones and I can say that we got just tremendous performance increase!

Anyway, I suppose that JSF is very prominent and have great potential!

-------------
Sincerely,
Andrew Sazonov
http://www.softamis.biz - High quality custom Java and Web Solutions.

Actually, we wanted to add quite specific functionality that probably is important for just special class of Web application - ones that are data oriented. That functionality included very dynamic assembling of web pages based set of predefined fragments and dynamic graphs of POJO obtained from application server (something like Tiles on steroids) and one of goals that we tried to achieve was very clean separation between UI designers and developers (actually, designers were not familiar with Java and JSP).

One approach to this kind of situation is a very interesting bit of code (currently code-named "clay") that has been proposed to be added to Shale (http://wiki.apache.org/struts/StrutsShale). The code (and a proof of concept app) is sitting in an attachment to an issue in the tracking system (http://issues.apache.org/bugzilla/show_bug.cgi?id=33752).

The basic idea is that you define reusable chunks of markup as a trees of components at a level smaller than a page (say, an Address Update form), like you might do with a Tile. Then, in the component that adds this reusable chunk of components into the component tree, it lets you go down and tweak the properties of the added components (like, what managed bean do the value binding expressions point at) so you can customize this use of the pattern to your particular needs.

This provides the guts of fine grained reusable chunks; the remaining piece (as you point out) is layout management. I believe that too can be handled with building suitable components.

Best part of the whole scenario: no changes required to JSF at all to do this; it runs fine on the JSF RI or MyFaces today.

Craig McClanahan

Craig,

Thank you for you point.

Yes, Clay is very interesting! It's funny - we've used pretty similar approach (yet more granular).

Since all our UI was based on appropriate Java beans, almost every component (it was not JSF component, but general idea is pretty close) we rendered was represented property of bean (of course, except such components as table, PageBar, navigation etc).

We've just defined set of common properties and how they should be rendered (we called them "Property Domains").

<propertyDomain id="phone" dataType="string">
 <edit>
  <label key="domains.phone.editLabel" lfType="label"/>
  <editControl controlType="split" rendererType=”simple” sizeCols="21">
  <parameters>
    <parameter name="pattern" value="nnn-nnn-nnnn"/>
  </parameters>
</editControl>
<data maxLength="21" validatorRuleID="phone"/>
...........

Later, we've described form fragmens for bean as composition of layout and properties (something like this part)
<beanUI className="shared.dto.Bank">
<edit>
 .....
  <group defaultColumnCount="2">
   <editProperty name="phone" domainID="phone"/>
   <editProperty name="phoneExt" domainID="phoneExt"/> </group>

And later we’ve combined the entire form based on structure of bean and fragments:

<form id="BankForm">
  <newForm simpleMode="no" allExpanded="yes" action="?command=form_new&amp;bean=Bank">
 <presentation defaultColumnCount="1" />
<supportedEntities>
 <entity uiType="edit" entityClassName="shared.dto.Bank"/>
 <entity uiType="view" entityClassName="shared.dto.Account"/>

Due to such separation of notion we were able to get very flexible architecture that allowed us making changes (both during development and support) pretty easy.

Of course, all this parts were assembled automatically (we've used rewritten Struts RequestProcessor and used custom Actions). Therefore, developer was only responsible to write code which provides model bean and designer was responsible to write XML based markup.

It obvious that probably this quite specific solution (and problem domain) that does not important for most of sites, but for ones that are busines oriented it works very good.

Well, thank you for your point again - we'll definitely look deeper to JSF, Shale and Clay. I'm really exciting thinking that we'll be able to use our own frameworks together with JSF.

Best regards,
Andrew Sazonov

Well, thank you for your point again - we'll definitely look deeper to JSF, Shale and Clay. I'm really exciting thinking that we'll be able to use our own frameworks together with JSF. Best regards, Andrew Sazonov

I think that's one of the key features of JSF. Sure, 1.0 didn't have dozens of components or bells and whistles, but it's extremely extensible and flexible. And it's very suitable as a foundation for other web user interface frameworks. I think we've only scratched the surface of its flexibility, which is available at multiple levels -- the EL, the render kit, managed beans, etc.

Kito D. Mann (JSP 2.1 and JSF 1.2 EG member)
http://www.JSFCentral.com - JSF FAQ, news, and info

Are you using JSF in a project? Send an e-mail to trenches at jsfcentral dot com and you could win a free copy of JavaServer Faces in Action!

Yes, Clay is very interesting! It's funny - we've used pretty similar approach (yet more granular).

Since all our UI was based on appropriate Java beans, almost every component (it was not JSF component, but general idea is pretty close) we rendered was represented property of bean (of course, except such components as table, PageBar, navigation etc).

Why do not use Tapestry that does all that and allows developing pages and components in Dreamveawer or FP?

A standard approach to reusing areas of markup plus functionality is exactly what is missing the most imo in JSF 1.2. When building a large webapp you immediately start identifying page-parts/functionality that are shared across pages but this is not facilitated at all by JSF. It is not viable to componentize them to JSF components since then you effectively lose JSP as a template mechanism (*) and have to writeout all your markup to a printwriter.
So then you'll have to fall back on using dynamic JSP includes and parametrization, which is clunky in the extreme.
In my experience, we've been developing using JSF for more than a year now, this heavily influences the opinion that not-convinced developers have of JSF.
JSF 1.1 was vendor-oriented, please make JSF 1.2 more developer-/project-oriented.

A standard approach to reusing areas of markup plus functionality is exactly what is missing the most imo in JSF 1.2. When building a large webapp you immediately start identifying page-parts/functionality that are shared across pages but this is not facilitated at all by JSF.

Again, Tapestry addresses exactly this arean, and does that nearly perfect.

A standard approach to reusing areas of markup plus functionality is exactly what is missing the most imo in JSF 1.2. When building a large webapp you immediately start identifying page-parts/functionality that are shared across pages but this is not facilitated at all by JSF.

Ever tried the "aliasBean" component from MyFaces? Makes JSP fragment reuse a breeze in JSF.

Mike

I've tried to post my reply here but "The message body contains invalid HTML". Please refer to http://www.mernst.org/blog/index.html

Matthias, the problem is https: change to http: instead and links will work. It's been noted before and is on the list of things to fix.

Luckily, the java.net links work with http as well as https.

Thanks Jospeph, here we go again:

JSP lacks in so many ways.

* reusable markup: tag files should have an invocation api from Java. I once hacked Jasper to allow that. You could get a SimpleTag instance for a path and invoke it. Spec people weren't interested. Promised me something else exciting - I'm still waiting.
* The grand unified EL still cannot call methods. ${content.isVisibleTo(user)} ?
* JSPs can't be called from somewhere else than the web app. Template staging in a CMS? No way.
* JSPs need compilation. Precompile, ja ja.
* Look ma, no escaping. Oh you're doing markup? Please use a taglib. Otherwise welcome scripting attacks.

I've had it. That's why I'd like to advertise a lightweight, fast, embeddable, XML-centric template engine I've built: http://axt.dev.java.net

The question is rather slightly different - is general JSF page lifecycle flexible enough to be truly view-agnostic? We've tried to combine JSF and XML based definition of UI. However, we found that is was complicated to make such integration in conformance with general lifecycle supported by JSF without changing lifecycle.

JSF allows for plugable lifecycle listeners and by using delegators/wrappers, you can extend the functionality of any JSF application concern provided by the vendor. I realize what you are getting at with possibly translating desktop/swing lifecycles to JSF's request/response lifecycle, but again, it can be done by implementing a ViewHandler/StateManager that works with Dialogs/Frames on the screen and allows JSF to update them, then re-pass them to the ViewHandler/StateManager for updating the screen again after some event has occured. Others may be able to clarify this in more detail or offer similar solutions.

Actually, we wanted to add quite specific functionality that probably is important for just special class of Web application - ones that are data oriented. That functionality included very dynamic assembling of web pages based set of predefined fragments and dynamic graphs of POJO obtained from application server (something like Tiles on steroids) and one of goals that we tried to achieve was very clean separation between UI designers and developers (actually, designers were not familiar with Java and JSP).Please note that we've tried to do this using Sun RI that is based on previous version of JSF so currently situation may be changed - I'm very interested to check it in new specification.

When JSF documents are created (at least with JSP), developers can leverage the 'binding' attribute to pull predefined components into the page in order to participate in rendering and updating. Also, JSF's managed bean specification allows you to use your own POJOs and have JSF components act upon them using EL-- which you probably already know ;-)

By the way, is it planned to add some support of layout managers (similar to ones used in Swing) to JSF? We've implemented our own ones and I can say that we got just tremendous performance increase! Anyway, I suppose that JSF is very prominent and have great potential!

Ed Burns (the JSF Spec lead) had posted a sample application that integrates with OpenSymphony's SiteMesh for layout management (project on java.net). But for other things like GridBag layouts, there are some of us in the EG that are against having JSF render *structure* that dictates the layout within HTML. The current trend in web application development is to keep the rendered structure clean and simple-- leaving layout concerns up to seperate CSS documents.

-- Jacob (JSR 252 EG & EL Alignment)

every new spec for jsp require new tomcat release, so r the developers begining the 6.x series or what?
what is the relation between the tomcat team and myfaces ? i think it is time for collaboration

every new spec for jsp require new tomcat release, so r the developers begining the 6.x series or what?what is the relation between the tomcat team and myfaces ? i think it is time for collaboration

yes,i hava the same question,anyone answer ?

every new spec for jsp require new tomcat release, so r the developers begining the 6.x series or what?what is the relation between the tomcat team and myfaces ? i think it is time for collaboration

yes,i hava the same question,anyone answer ?

I'm not sure of the timeline, but Glassfish (Sun's Open Source App Server) uses Tomcat which is JSP 2.1 compliant with all of the new EL features along side JSF.

http://glassfish.dev.java.net

jsf have serious problems when dealing with page composition and decoration technologies such as tiles and sitemesh, is the new spec address this? another related thind ,can they provide a standard mechanism composing dynamic url for the page tiles or fragments so it does not need to b changed when we move the tile or the action to another location?

we really need standard spec for integrating with portlet specs jsr168 as all available now is propriatory bridges either in the ri or myfaces, we really need standard way to integrate and run jsf inside jsr168 portlets

we really need standard spec for integrating with portlet specs jsr168 as all available now is propriatory bridges either in the ri or myfaces, we really need standard way to integrate and run jsf inside jsr168 portlets

Well, I think you're confusing _standard_ with _implementation_. As of today, JSF and Portlets work well together (as far as the specifications are concerned).

As far as implementations go, as long as each JSF implementation has a portlet bridge, then I think we're okay. Chances are that just about every implementation from now on will be based either on the RI or MyFaces anyway. The JSF RI's portlet bridge isn't yet production ready, though, which is a concern.

I've been working through some issues with MyFaces portlets and Liferay, but I think all of those problems were in Liferay's court...

Kito D. Mann (JSF 1.2 and JSP 2.1 EG member)
http://www.JSFCentral.com - JSF FAQ, news, and info

Are you using JSF in a project? Send an e-mail to trenches at jsfcentral dot com and you could win a free copy of JavaServer Faces in Action!

we really need standard spec for integrating with portlet specs jsr168 as all available now is propriatory bridges either in the ri or myfaces, we really need standard way to integrate and run jsf inside jsr168 portlets

I'm not sure what you are referring to. Both MyFaces and the RI have portlet integration. I have several JSF apps that run unchanged as stand-alone or as a portal.

Is there something specific that you don't like about spec/implementation for this?

Stan

This version numbering for JSF is rather wrong!

Version 1.2 should be labeled 1.0 as this will be really the first production useful version of JSF!

Version 1.0 should have been 0.8, and 1.1 should have been 0.9!

Will Jakarta Commons EL implement the new javax.el API?

http://jakarta.apache.org/commons/el/

Will Jakarta Commons EL implement the new javax.el API?http://jakarta.apache.org/commons/el/

Yep, Kin-man, from Sun, has gotten commons-el aligned with the new EL-API. I'm not sure when it will be available to the public, but one of the neat things about the new EL-API is that it doesn't require a Servlet Container to run, so you can integrate EL with any framework or business application.

-- Jacob (JSR 252 EG & EL Alignment)

Why do not use OGNL(http://www.ognl.org/)?

Why do not use OGNL(http://www.ognl.org/)?

EL was created with a specific purpose in supporting read/view operations. While OGNL has more features, it also opens more complexity beyond simple dot notation for walking object graphs. Some may appreciate the simplicity within the view, while others find it limiting.

While OGNL has more features, it also opens more complexity beyond simple dot notation for walking object graphs. Some may appreciate the simplicity within the view, while others find it limiting.

OGNL provides _exactly_ the same dotted syntax for simple (EL like) use, so they are equal for lower end use.

 And because OGNL is free from EL limitations I think that OGNL should be promoted and EL simply dropped.

I've found the EL to be limited even when walking object graphs. For instance, if the object implements map it isn't going to walk it's graph, it will just return null for methods whose <bean>name is not a key in the map. It also is only capable of calling bean methods so to say it is walking the object graph is a stretch.

Will be posible with FACES process data on server and return results without reloading page..??

Cesar
ibSoft Development

Will be posible with FACES process data on server and return results without reloading page..??CesaribSoft Development

It's up to the creator of the the JSF component. JSFCentral.com has a big list of components available for use, many of them use AJAX. At JavaOne, there were thousands of developers that attended presentations that showed off rich JSF components backed by AJAX.