JSF 2.0 Early Access Review Available

Discussions

News: JSF 2.0 Early Access Review Available

  1. JSF 2.0 Early Access Review Available (12 messages)

    The JSF 2.0 Expert Group has released an Early Access Draft of the new spec, and is soliciting feedback. The feedback period runs from yesterday (June 2) to July 2. More details, and the draft itself, can be found on the JSR 314 JCP page. Ed, Ryan, Roger, and others from the Mojarra team are working on an EA implementation, with plans to make it available via various means, including the GlassFish Update Center. If you would like to influence the upcoming revision of the spec, now is the time to speak up!

    Threaded Messages (12)

  2. Good to know[ Go to top ]

    I love that Facelets support is now part of the JSF specification (as of 2.0). Java EE container-managed resource injection via annotations in backing beans is great news. JSF is evolving nicely! Where is the @ManagedBean annotation? I think we desperately need one like this in the JSF spec. Seam fills this niche very nicely, and I imagine that Web Beans will standardize this approach. Would it be too much to ask for 100% annotation-driven configuration for managed beans, properties and scopes as an alternative to XML? Why not for converters and validators too? Is JSF still contending in the dependency injection space or will the managed beans facility too become an externalized/pluggable feature like EL, PDL, etc.? I'm impressed with the early access draft and very much looking forward to the the future of Web development on the Java platform with JSF. Ian Hlavats JSFToolbox - Design JSF Pages in Dreamweaver Read my article on JSFCentral.com
  3. Re: Good to know[ Go to top ]

    I love that Facelets support is now part of the JSF specification (as of 2.0).

    Java EE container-managed resource injection via annotations in backing beans is great news.

    JSF is evolving nicely!

    Where is the @ManagedBean annotation?

    I think we desperately need one like this in the JSF spec.

    Seam fills this niche very nicely, and I imagine that Web Beans will standardize this approach.

    Would it be too much to ask for 100% annotation-driven configuration for managed beans, properties and scopes as an alternative to XML? Why not for converters and validators too?

    Is JSF still contending in the dependency injection space or will the managed beans facility too become an externalized/pluggable feature like EL, PDL, etc.?

    I'm impressed with the early access draft and very much looking forward to the the future of Web development on the Java platform with JSF.

    Ian Hlavats
    JSFToolbox - Design JSF Pages in Dreamweaver
    Read my article on JSFCentral.com
    Actually the managed beans always have been pluggable via the VarableResolver/ElResolver, frameworks like Spring or Seam build upon it. I don´t think too many jsf applications in the wild use the native managed bean facilities they are there however if there is no need for a big framework like Spring or Seam. It is rather easy to replace the native variable resolver with a custom one it is just a few lines of code.
  4. Re: Good to know[ Go to top ]

    Where is the @ManagedBean annotation?

    I think we desperately need one like this in the JSF spec.
    I wouldn't say I need it desperately, but it surely would be a nice addition. It would play well with the general theme in Java EE that you can express something either with annotations or with XML. This has been done very consistently in EJB3 and if I understand correctly it is also planned for Servlet 3. It would really be a great addition to JSF. One thing I would like to see too in managed beans, is converters and validaters which you can attach directly to a managed bean. Currently you attach them your UIComponent, which then, based on the outcome, updates your managed bean or not. Most of the times this works great, but unfortunately it doesn't work when you make heavy use of the dependency injection features in the managed bean declarations. E.g. something like: foo#{param.foo} Currently I have to do some manual conversion and validation in an @postcontruct method. Support for this in the managed bean declaration through XML, or optionally with an annotation directly on the getter or setter of the bean would be absolutely great! foo#{param.foo} or foo#{param.foo} While we're at it, something which slightly bothers me in the XML syntax of JSF is that its designed seemed to have overlooked the existence of XML attributes. JSF XML is fairly verbose. Using attributes could really reduce its size and make it more readable. E.g. compare: customerOrders com.mycompany.view.customer.orders.customerOrdersBacking request foo#{param.foo} with It might be me, but I find the latter to be much better for readability. As an isolated example it might only be a small effect, but if you have files with a lot of beans with each a lot of managed properties etc, this all adds up pretty fast. For some situations elements might be still be preferable to attributes, so here too the best option might be to give the programmer a choice.
  5. Re: Good to know[ Go to top ]

    I love that Facelets support is now part of the JSF specification (as of 2.0).

    Java EE container-managed resource injection via annotations in backing beans is great news.

    JSF is evolving nicely!

    Where is the @ManagedBean annotation?

    I think we desperately need one like this in the JSF spec.

    Seam fills this niche very nicely, and I imagine that Web Beans will standardize this approach.

    Would it be too much to ask for 100% annotation-driven configuration for managed beans, properties and scopes as an alternative to XML? Why not for converters and validators too?
    That's coming. You can see the road map for features and draft release here: http://tinyurl.com/4kon49 I don't see it on the list, but we intend to have annotations for just about everything in faces-config.xml by the PFD at the latest. We've already discussed that a fair amount already, though it hasn't been worked into the spec. When I see Ed Burns, I'll ask him about that.
    Is JSF still contending in the dependency injection space or will the managed beans facility too become an externalized/pluggable feature like EL, PDL, etc.?
    I'm not sure JSF was ever intended to contend in the IoC market, but was given light-weight IoC features to meet the need for it, while at the same time not requiring an external library. (That's my assessment, at any rate). As we pointed out, the ELResolver is pluggable, so one can easily replace this piece if you want.
  6. SF Spec should address AJAX part along with Server Push (I saw these topics in JSF draft spec) It should also be able to support client side rendering with Entities and BackingBean callable from javascript (like seam remoting) and it should also support storage abstraction as IE8 and Firefox3 has it inbuilt. Otherwise again it will suffer same fate of earlier jsf where industry is moving in one direction and jsf is taking another. If i want to compose application using javascript, html, css alone in the client side without using JSP/JSF for every request in the server side (minimal framework components based on servlet or jsf), i can do it with Seam Remoting and Dojo. I can develop a true model/view/controller in java script and expose my services or beans or whatever components as javascript component by having javascript to java communication layer fabricating security and other aspects into it. So how does JSF support this? The very idea is lot of Javascript frameworks exists like GWT, Dojo, YUI, JQuery etc, those are specifically focused on client side computing, is there a way in new JSF spec which eases integration with these fw, so that we can give a great UI by exploiting them. It is much difficult to focus both client side and server side in speed with specific fw mentioned above. But there should be a way to leverage them. Otherwise money/time/effort spent on standardizing will not be usable by major crowd.
  7. Effective use of Ajax techniques[ Go to top ]

    I think Making it easy to create responsive user interfaces through effective use of Ajax techniques is one of the most important things that JSF2.0 will have.
  8. Cornerstone changes first[ Go to top ]

    I like to see that JSF spec is evolved, but IMO too much efforts are put to implementation specific details (resources, facelets, ajax), whereas most responsibility of specification team should be to establish solid cornerstone API which will allow flexible development on top of it. For now, most of you will agree with me, that JSF API is far from perfect. The most flawed parts need to be redesigned prior to others are IMO UIComponents hierarchy, state handling, error handling and bootstrap/configuration/hooks. Its very surprising to me that nobody in JSF spec team seems pay attention to very fruitful ideas described by Jacob Hookom in his blog http://hookom.blogspot.com/ 1-2 years ago. See especially posts JSF 2.0 Ideas (October 26, 2006) and "More JSF 2 Ideas" (May 13, 2007) In addition to this, my ideas are following: UIComponent API should be as much lightweight and declarative as possible (Interfaces + annotations instead of superclasses and implementations). This should allow later bytecode instrumentation at runtime. State management should be revised significantly. In 99% of applications tree structure and most attributes are static and can have application level scope rather than request scope, thus for example, tree navigation can be shared between concurrent requests. IMO there should be explicit support for stateless pages, I mean, by default pages should be stateless, and there should be special explicit page scope and correspondent API, similar to Session API in servlets, allowing applications and components save/restore only state explicitly need to be associated with the page. Alternatively, declarative approach for state saving proposed by Jacob is very great idea too. Bootstrap/configuration/hooks part is too very important, for now too much efforts are required to initialize most JSF parts in correct order. I'd add here special initialization hooks, per-component hooks, more generic support of component tree traversal using visitors. Error handling no doubt should be improved, at least phase listeners should be able to react and catch exceptions thrown during any request phase, with simplified dispatching facilities to bind some error pages to logical outcomes. Speaking of composite components building, I'm almost satisfied with facelets support, the only problem to solve here is lack of parameterized expression support, but I think this can be solved with declarative component attributes. Having this solid ground, we will be able to build richer set of functionality later.
  9. ++Dmitry[ Go to top ]

    Dmitry, I couldn't agree more. You mentioned most important issues that really bug everyone! I would also love to see some elegant solution to having "pages with nice a la permalink names" and in general better developer control over the navigation behavior (something in the spirit or spring MVC modular navigation) beyond he xml configuration based navigation. The Facelets addition is obviously a must. Yuval Goldstein.
  10. In the current JSF version, there is no link or reference between Managed Bean and Phase Listener. In JSF2.0 if they bring some way to link managed bean and phase listener tightly will be much helpful.
  11. In the current JSF version, there is no link or reference between Managed Bean and Phase Listener.
    What do you mean exactly by that? Surely a managed bean can either be a Phase Listener itself, or it can give back a reference to another Phase Listener. The Phase Listener instance can then either be a completely separate class or it can be an inner class of the Managed Bean. Seems to me like a great deal of linking is possible there, but perhaps you meant something else?
  12. Surely a managed bean can either be a Phase Listener itself, or it can give back a reference to another Phase Listener. The Phase Listener instance can then either be a completely separate class or it can be an inner class of the Managed Bean.
    How to make managed bean and phase listener as same instance? creates new instance for the specified class. My intention is if phase listener and managed beans are linked I can write custom validation and custom bean update codes easily.
  13. Swing Render Kit?[ Go to top ]

    Unrelated to this thread but... The other day while looking at Oracle ADF JSF components I was wondering if anyone has tried to write a Swing render kit? I mean create Swing based fat client forms with JSFish xml notation and tags and let a Swing render kit convert it to Swing api calls, in runtime or perhaps in compile time as a code genration step? Is it a good idea? Is it feasible? Doable? Done already? Has the Swing or JSF expert groups considered such a thing for unifying client and req/response based UI definitions? Ara.