JSF 2.0 Early Draft Review 2 Available

Discussions

News: JSF 2.0 Early Draft Review 2 Available

  1. JSF 2.0 Early Draft Review 2 Available (44 messages)

    Ed Burns, the JSF 2.0 co-spec lead (along with Roger Kitain), has pointed out the availability of the JSF 2.0 early draft review 2 specification. This incorporates early implementations of composite components and AJAX support. An ,implementation of the draft is also online, although the testing kit isn't complete. JSF 2.0 is a logical and necessary evolution of JSF; the only real question is whether it will be popular enough to compete against the more agile, less stable (specification-wise!) frameworks.

    Threaded Messages (44)

  2. It will compete well, It looks very interesting and I think after reading all the drafts and specs of JSF 2 already is in the right direction. When do you think it will be the project Mojarra have a release?, I really would like to start a project with JSF2.
  3. Congratulations to the JSF 2.0 team on releasing the public draft. I will read it ASAP and provide comments. The EJB 3.1 public draft should be out shortly as well. I am coinciding the my last EJB 3.1 preview article with the release of the public draft. I hope Joe/Peter will have a separate announcement for the EJB 3.1 public draft as well. Cheers, Reza
  4. I hope Joe/Peter will have a separate announcement for the EJB 3.1 public draft as well.
    It's all Peter, Reza - I have no formal relationship with TSS any more. I'm only a rank and file user like the rest of you are.
  5. I wonder if the early implementation and draft spec include the HTTP GET url support instead of POST for everything? (aka bookmarkable urls) I did a quick search in the PDF for HTTP GET and Bookmark but didn't come up with anything that described this functionality.
  6. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    I wonder if the early implementation and draft spec include the HTTP GET url support instead of POST for everything? (aka bookmarkable urls)

    I did a quick search in the PDF for HTTP GET and Bookmark but didn't come up with anything that described this functionality.
    It's not in this draft release, but it IS coming. :)
  7. Get your priorities right![ Go to top ]

    I wonder if the early implementation and draft spec include the HTTP GET url support instead of POST for everything? (aka bookmarkable urls)

    I did a quick search in the PDF for HTTP GET and Bookmark but didn't come up with anything that described this functionality.

    It's not in this draft release, but it IS coming. :)
    Jeez... I'd think that is probably one of the most important thing... not everyone wants to build Ajax based interfaces. With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..
  8. Re: Get your priorities right![ Go to top ]

    Jeez... I'd think that is probably one of the most important thing... not everyone wants to build Ajax based interfaces.

    With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..
    There are some libraries out there (and frameworks) solving the issue about GET requests in JavaServer Faces. One of this is RestFaces (https://restfaces.dev.java.net/, I work on this project). Others are Seam, SpringFaces, ... I understand that this aspect should be solved at spec level too. Anyway nowadays you already have some good solutions.
  9. I know[ Go to top ]

    Jeez... I'd think that is probably one of the most important thing... not everyone wants to build Ajax based interfaces.

    With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..


    There are some libraries out there (and frameworks) solving the issue about GET requests in JavaServer Faces.

    One of this is RestFaces (https://restfaces.dev.java.net/, I work on this project).
    Others are Seam, SpringFaces, ...

    I understand that this aspect should be solved at spec level too. Anyway nowadays you already have some good solutions.
    I know. I've solved it myself too. The point is you'd think something trivial yet important is up there in the priority list.... shiny new toys should at do what the old rusted one does
  10. Re: I know[ Go to top ]

    Why continue with an outdated and broken framework?, JSF is an over-engineered piece of garbage. When you build something strong from it's roots it will be strong in the future but JSF was a complete mess since day 1. Save your self and try GWT or Wicket are much better frameworks, JSF folks doesn't get it.
  11. Relax. Why you need to be so aggressive with a technology and also the people that are involved with it? It's just a framework, a bunch of code. "Peace and love" between JSF, wicket, ruby, phyton, java... No matter if we like or not those technologies, they will need to be integrated anyway. Yara
  12. Re: I know[ Go to top ]

    Why continue with an outdated and broken framework?, JSF is an over-engineered piece of garbage.

    When you build something strong from it's roots it will be strong in the future but JSF was a complete mess since day 1.

    Save your self and try GWT or Wicket are much better frameworks, JSF folks doesn't get it.
    Otengi, Your comment is another example of a JSF bashing trend I have observed on TSS. The argument is usually a variation of "JSF is bad, framework X is better", and is usually coming from users of framework X. If you don't like JSF, simply don't use it, but please spare us your whining. Many people are using JSF and are quite happy with it and appreciate the MVC design and stability of JSF as a Java standard. You will also notice that JSF users bashing non-JSF web frameworks on TSS never happens (I have yet to see an example). What does this suggest? Maybe JSF users are happy and do not feel the need to attack Wicket, Tapestry, GWT, or whatever. There are many reasons to continue with JSF: reusable Ajax-enabled UI components for the Web, nice MVC-style separation of concerns (Web page designers and Java developers can actually work together and leverage their skill sets), extensible conversion/validation, easy I18N, broad tool support, etc. etc. I am sure you can make the same case for framework X, so let's not get into a framework debate here. The point is that unless you have something constructive to say, please say it elsewhere. Ian Hlavats JSFToolbox - Design JSF Pages in Dreamweaver Read my article on JSFCentral.com
  13. Re: I know[ Go to top ]

    Why continue with an outdated and broken framework?, JSF is an over-engineered piece of garbage.

    When you build something strong from it's roots it will be strong in the future but JSF was a complete mess since day 1.

    Save your self and try GWT or Wicket are much better frameworks, JSF folks doesn't get it.

    Otengi,

    Your comment is another example of a JSF bashing trend I have observed on TSS. The argument is usually a variation of "JSF is bad, framework X is better", and is usually coming from users of framework X.

    If you don't like JSF, simply don't use it, but please spare us your whining. Many people are using JSF and are quite happy with it and appreciate the MVC design and stability of JSF as a Java standard.

    You will also notice that JSF users bashing non-JSF web frameworks on TSS never happens (I have yet to see an example). What does this suggest? Maybe JSF users are happy and do not feel the need to attack Wicket, Tapestry, GWT, or whatever.

    There are many reasons to continue with JSF: reusable Ajax-enabled UI components for the Web, nice MVC-style separation of concerns (Web page designers and Java developers can actually work together and leverage their skill sets), extensible conversion/validation, easy I18N, broad tool support, etc. etc.

    I am sure you can make the same case for framework X, so let's not get into a framework debate here. The point is that unless you have something constructive to say, please say it elsewhere.

    Ian Hlavats
    JSFToolbox - Design JSF Pages in Dreamweaver
    Read my article on JSFCentral.com
    Actually I was a JSF user but as I said it is over-engineered and a mess to work with. Now I work with another frameworks not just one because every framework have their strong and weakness. I use now Wicket, Tapestry, GWT and Stripes. I don't think people is happy to use JSF I assure you but they have to use it at work because is the standard. Why JSF users doesn't bash another frameworks because they don't have noting to bash with, they know the other frameworks are much better. Ask to any Java developer in the street and he/she will tell you similar as I'm saying here. Yes I'm bashing JSF because is the True. Regards.
  14. Re: I know[ Go to top ]

    Ask to any Java developer in the street and he/she will tell you similar as I'm saying here.

    Yes I'm bashing JSF because is the True.

    Regards.
    Actually if I am any java developer, I really like the framework... It has its weaknesses true, but so do others. ;-)
  15. Re: I know[ Go to top ]

    Yes all the frameworks have weaknesses but "JSF 1.2" thousands compare with other frameworks. I really hope the JSF team get it right with 2.0 but I think it taking to long because have to refactor all the mess that is JSF 1.2. My point is JSF2 maybe is getting in the right direction but JSF1 it was a complete mess. Regards.
  16. Re: I know[ Go to top ]

    Yes all the frameworks have weaknesses but "JSF 1.2" thousands compare with other frameworks.

    I really hope the JSF team get it right with 2.0 but I think it taking to long because have to refactor all the mess that is JSF 1.2.

    My point is JSF2 maybe is getting in the right direction but JSF1 it was a complete mess.

    Regards.
    Actually the only real weaknesses I know of are following No standardized way to handle ajax No standardized end user way to handle http get (the poster before pointed it out how to handle it on the framework side) And a lack of more standardized default controls The list is pretty low, but in my experience the http get problem is the most serious one in the real world, but definitely at least not for me a reason to drop jsf!
  17. Re: I know[ Go to top ]

    Ask to any Java developer in the street and he/she will tell you similar as I'm saying here.

    Yes I'm bashing JSF because is the True.

    Regards.


    Actually if I am any java developer, I really like the framework... It has its weaknesses true, but so do others.
    ;-)
    But others have less weaknesses. JSF is too complex In my company I made a small test - NONE of those who advocated for JSF managed to tell me JSF's lifecycle without making a mistake. JSF isn't good for AJAX If you try to use one Ajax component from one lib with component from the other lib you 'll most likely fail. If you try to develop own AJAX JSF component and won't switch to GWT,ECHO2, or Wicket you are probably masochist. JSF is HARD to DEBUG and TEST Try to write unit tests for JSF application and compare it with GWT. Or try to debug (don't do it at home) AJAX JSF application if you really like masochistic frameworks. Regards
  18. Re: I know[ Go to top ]

    Ask to any Java developer in the street and he/she will tell you similar as I'm saying here.

    Yes I'm bashing JSF because is the True.

    Regards.


    Actually if I am any java developer, I really like the framework... It has its weaknesses true, but so do others.
    ;-)


    But others have less weaknesses.

    JSF is too complex
    In my company I made a small test - NONE of those who advocated for JSF managed to tell me JSF's lifecycle without making a mistake.

    JSF isn't good for AJAX
    If you try to use one Ajax component from one lib with component from the other lib you 'll most likely fail.
    If you try to develop own AJAX JSF component and won't switch to GWT,ECHO2, or Wicket you are probably masochist.

    JSF is HARD to DEBUG and TEST
    Try to write unit tests for JSF application and compare it with GWT. Or try to debug (don't do it at home) AJAX JSF application if you really like masochistic frameworks.

    Regards
    For the lifecycle, point taken I agree here, way too many phases, hence most view controllers cut it down to sane 4. As for Ajax the problem is within the Ajax realm myself, my day to day job is heavily working in Ajax, and if you dont use a lib which shields yourself from the mess underneath (Browsers DOM + Javascript) you are in for hell, the problem lies not in the applied framework but where you want to have the abstraction. I personally prefer to use frameworks which try to cover the browser abstractions instead of trying to use a lib which tries to cover everything. Have you ever tried to isolate a single problem in the GWT generated sources or to influence the internals of ECHO2 :-) Seriously Ajax itself is a bad solution, JSF is not at fault there. Libraries which try to cover it at the core are easier to handle in some regards because you do not component mixing and mixing of various Ajax underpinnings. Libs like richfaces fare pretty well in their respective domain but mixing something else in is the same as you would mix protoype with dojo and jquery, you ask for trouble. The problem is as I said in the realm of Ajax itself which does not have a proper encapsulation of components and dom subtrees on a standards level! As for hard to debug and test I cannot agree here, there are two well working test frameworks in existence which you simply put on top of jsf, there are toolings for the lifecycle trace etc...
  19. Re: I know[ Go to top ]

    Ask to any Java developer in the street and he/she will tell you similar as I'm saying here.

    Yes I'm bashing JSF because is the True.

    Regards.


    Actually if I am any java developer, I really like the framework... It has its weaknesses true, but so do others.
    ;-)


    But others have less weaknesses.

    JSF is too complex
    In my company I made a small test - NONE of those who advocated for JSF managed to tell me JSF's lifecycle without making a mistake.

    JSF isn't good for AJAX
    If you try to use one Ajax component from one lib with component from the other lib you 'll most likely fail.
    If you try to develop own AJAX JSF component and won't switch to GWT,ECHO2, or Wicket you are probably masochist.

    JSF is HARD to DEBUG and TEST
    Try to write unit tests for JSF application and compare it with GWT. Or try to debug (don't do it at home) AJAX JSF application if you really like masochistic frameworks.

    Regards
    +1, +1, and +1
  20. Re: I know[ Go to top ]

    JSF is too complex
    In my company I made a small test - NONE of those who advocated for JSF managed to tell me JSF's lifecycle without making a mistake.
    It sounds like you were testing your colleagues' memorization skills; you may get better results if you ask them to explain the JSF lifecycle in their own words. JSF is a complex, but so is a car. You don't have to know how the engine works in order to drive it, just like you don't have to know the internal details of the request processing lifecycle to understand how to build JSF applications. When I teach JSF courses I try to avoid confusing students by over-emphasizing the JSF lifecycle. The whole lifecycle can be summarized as follows: "When you access a JSF page, the page calls the getters of your backing bean and renders the data. When you submit a form, JSF converts user input (strings) to Java types (dates, integers, etc.), validates the data, copies it to your backing bean (calls the setters), then calls your backing bean action method". The important things to know from an application developer perspective are (a) UI components, (b) backing beans, and (c) Model-View-Controller. Once you understand the big picture (JSF's multi-client UI component paradigm) it's much easier to learn JSF development. The rest is just details (e.g. how to do I18N, event handling, data binding, conversion, validation, etc).
    JSF is HARD to DEBUG and TEST
    Try to write unit tests for JSF application and compare it with GWT.
    Sorry, but this is false. If you use Seam, then unit testing your JSF applications is very easy. You can easily write a TestNG test harness based on your JSF views that instantiates your UI components and simulates the full request processing lifecycle, including request parameters, transactions, EJB3 component lifecycle, JMS messaging, data sources, connection pools, etc. The whole thing fires up in about 15-20 seconds and away you go. There is also JSFUnit, by I haven't tried this yet.
    JSF isn't good for AJAX
    If you try to use one Ajax component from one lib with component from the other lib you 'll most likely fail.
    This is a valid point, however the JSF 2.0 spec addresses this issue and Ajax will be standardized in JSF so compatibility issues will go away.
  21. Re: I know[ Go to top ]

    JSF isn't good for AJAX
    If you try to use one Ajax component from one lib with component from the other lib you 'll most likely fail.

    This is a valid point, however the JSF 2.0 spec addresses this issue and Ajax will be standardized in JSF so compatibility issues will go away. That depends how you see it, the general perspective of ajax being hard being put aside, I dont think JSF is harder on ajax than any other framework. I have done so many Ajax bindings to JSF myself that it comes quite naturally. Maybe that field needs the same as solving the http get problem simply more documentation. The trick as always is to use phase listeners on the server side to fetch the data being sent down by the ajax call and vice versa. Not much harder than being in the servlet realm where you have to fetch the data from the request. But the same as http get it is under documented and there needs to be a high level way to do it. Once you have the data there is no real problem anymore to reach the rest of the jsf infrastructure, not much harder than in the servlet domain! There is another problem but basically every framework doing server side component trees face it, if you do real client side ui programming without page refreshes, then it becomes hard to keep the server side component tree and its client side representation in sync. But that is a general problem of frameworks which try to cover both the server and the client side with component trees. You basically could use a starting state and then omit the entire server side aspect of jsf, or you could use ppr (which is another issue due to browser incompatibilities) My personal opinion regarding real client side interaction without page refreshes is, that the best bet to cover this in any framework is, to keep the server side aspect down to the bare minimum and do it the classical way, only client side with the server being delegated to a remote CRUD service layer! Reality is however that most frameworks follow a combined approach due to the fact that accessing components on the server side is a huge advantage! Those are things the normal application programmer should not care about. Things like Richfaces, Trinidad PPR or Webgalileo on the JSF side, or GWT take care of those aspects for you or at least should. Fact is unfortunately, that with those toolkits you only can reach 90-95% of what you need until you run into issues partially caused by the hoax the entire DHTML/Ajax approach in reality is once it comes down to classical UI design and then in any framework you use you have to go down deep into the trenches of the ajax layer (my personal tincan opener for this can of worms always is the inherent we still have to support IE6 requirement). And then I personally prefer a framework with maintainable Javascript instead of having a java-javascript compiler spitting out code (Sorry GWT but I simply do not like that approach) Ok this was getting OT, but I think the entire Ajax problem , and I see it as a problem and a load of antipatterns regarding remote UI design needs a little bit more discussion than a flamewar, despite that basically every framework in existence promises easy ajax, there is no easy ajax, brigther colors on a rotten house.
  22. Re: Get your priorities right![ Go to top ]

    Jeez... I'd think that is probably one of the most important thing... not everyone wants to build Ajax based interfaces.

    With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..
    Well, when the EG started prioritizing thingsk everyone got to "buy" a feature, where each person was given so much "money" and got to put some of that on the features he thought were important. This exercise was used to prioritize not only the features that we'd put in JSF 2, but also, to some extent, the order in which they implemented. More or less. Now, with respect to your... passionate plea, all I can say is this: It's going to get done. We just haven't done it yet. Keep in mind, also, that this is an early *draft* release. It's not meant for production use at this point, so, even if we DID have GET request worked into the spec, it would be imprudent to use the current state of the spec in current applications (of course, for longer development cycles, one might start building against the spec now). There's only so much time in the day, and the EG that has been assembled from a *wide* array of expertise and experience has done the best we can to prioritize as we felt appropriate. If it helps any, you're probably not the only one who has issues with the order of feature implementations. We're doing what we can to make a great rev of the spec as quickly as we can (and still do it right), but there's no way we can please everyone.
  23. Re: Get your priorities right![ Go to top ]

    With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..
    Steven, Your disappointment with JSF's POST requirement is like buying a Ferrari and then getting upset when you discover it's hard to race it in reverse... I have had this discussion before and I maintain my position that there is nothing wrong with JSF server-side event handling requiring POST. That's what POST was intended for! Do you remember the Google Web Accelerator? When this utility was first released, it caused major problems for a number of sites that used GET to modify server-side state because the software would aggressively follow links in web pages that would result in all kinds of undesired effects on the server. (Google later modified it so that only links without request parameters would be followed.) The point is that invoking application logic using GET is a bad idea and contravenes the HTTP specification. GET is supposed to be both safe and idempotent. URLs such as /myapp/customers/delete.do?id=12345 are inherently dangerous, much like racing a Ferrari in reverse. Ian
  24. Wrong assumption[ Go to top ]


    Steven,

    Your disappointment with JSF's POST requirement is like buying a Ferrari and then getting upset when you discover it's hard to race it in reverse...

    I have had this discussion before and I maintain my position that there is nothing wrong with JSF server-side event handling requiring POST.

    That's what POST was intended for!

    Do you remember the Google Web Accelerator? When this utility was first released, it caused major problems for a number of sites that used GET to modify server-side state because the software would aggressively follow links in web pages that would result in all kinds of undesired effects on the server. (Google later modified it so that only links without request parameters would be followed.)

    The point is that invoking application logic using GET is a bad idea and contravenes the HTTP specification. GET is supposed to be both safe and idempotent. URLs such as /myapp/customers/delete.do?id=12345 are inherently dangerous, much like racing a Ferrari in reverse.

    Ian
    Who says there is anything wrong with JSF handling requiring POST? Quote me. I'm saying JSF handling ONLY requiring POST is inadequate. You know there's no such thing as a silver bullet, one size fits all solution. There are plenty of valid cases where you want to have a GET request, such as a redirected GET after you POST where your request scoped state is transferred. So your analogy is incorrect, when i buy the Ferrari, I'm not expecting to race it in reverse, what I DO expect is to be able to drive at 15m/h, like any regular car, on residential areas without accidentally killing someone's pet rabbit. If you still dont get it, a ferrari can probably do that, but JSF is akin to one that doesnt. The fact that you have Seam extending its lifecycle to do that or numerous other workaround or "tools" that do that says something dont you think?
  25. Re: Wrong assumption[ Go to top ]

    The fact that you have Seam extending its lifecycle to do that or numerous other workaround or "tools" that do that says something dont you think?
    Yes, it says that JSF EG avoided the "kitchen sink" approach to framework design and decided to support extensibility instead. This is good framework design IMHO. JSF is more than a framework; it's an ecosystem. You have some of the top minds in the industry contributing components and framework extensions, such as JBoss Seam, Apache Tomahawk/Trinidad, Facelets, and the list goes on and on.
  26. I dont think so[ Go to top ]

    The fact that you have Seam extending its lifecycle to do that or numerous other workaround or "tools" that do that says something dont you think?

    Yes, it says that JSF EG avoided the "kitchen sink" approach to framework design and decided to support extensibility instead. This is good framework design IMHO.

    JSF is more than a framework; it's an ecosystem. You have some of the top minds in the industry contributing components and framework extensions, such as JBoss Seam, Apache Tomahawk/Trinidad, Facelets, and the list goes on and on.
    Point noted but that point is just a smokescreen. I'm not expecting JSF to provide the whole kitchen sink, but it should at least provide some very basic plumbing. GET handling is a very basic plumbing that pretty much even the most outdated frameworks support. Your excuse is pretty weak. Come come, try harder.
  27. Re: Get your priorities right![ Go to top ]

    With POST only out of the box (yea i know you can do some hacks to get GET working, been there done that), its really like selling a ferrari that can't go at constant 15km/h in residential areas without a trip to the garage to under-tune it.. this is 2008 for godsake..

    Steven,

    Your disappointment with JSF's POST requirement is like buying a Ferrari and then getting upset when you discover it's hard to race it in reverse...

    I have had this discussion before and I maintain my position that there is nothing wrong with JSF server-side event handling requiring POST.

    That's what POST was intended for!

    Do you remember the Google Web Accelerator? When this utility was first released, it caused major problems for a number of sites that used GET to modify server-side state because the software would aggressively follow links in web pages that would result in all kinds of undesired effects on the server. (Google later modified it so that only links without request parameters would be followed.)

    The point is that invoking application logic using GET is a bad idea and contravenes the HTTP specification. GET is supposed to be both safe and idempotent. URLs such as /myapp/customers/delete.do?id=12345 are inherently dangerous, much like racing a Ferrari in reverse.

    Ian
    I think one of the main issues is that it is rather hard to get a rest like load with standard JSF mechanisms. Yes it is doable, I did it myself, projects like restfaces do it. The main issue with the current specifications of JSF in this regard simply is, how to I map bean values to url parameters so that I can get a decent value to parameter mapping, the other issue is, that there is no view controller mechanism or another dedicated clear page init where applications can intercept to load the data shown. By fixing both of those issues, most pains people would have with JSF regarding Get would go away. And yes I agree it is inherently evil if you want to try to push everything into a HTTP get. I am probably to pragmatic and not academic enough to really see a sane thing into RESTING everything there is. But the problems JSF 1.+ has in this regard is that the get support you can get out of the box is almost non existent for the average application programmer who does not know his way around the existing addon frameworks or sits knee deep in the framework mechanisms. And for a typical site you definitely need those parametrized loading links to make the application behave properly regarding bookmarks and search engines. Or in other words like a good friend of mine recently said. JSF currently covers the complicated cases pretty well but lacks in coverage of the simple stuff.
  28. Re: Get your priorities right![ Go to top ]

    The main issue with the current specifications of JSF in this regard simply is, how to I map bean values to url parameters so that I can get a decent value to parameter mapping, the other issue is, that there is no view controller mechanism or another dedicated clear page init where applications can intercept to load the data shown.
    A clear page init point already exists IMHO, and it is a phase listener before RENDER_RESPONSE phase. I mean the mechanism is there, and would work very nice. The problem is the lack of some infrastructure upon this. Actually (without using restfaces or other libraries), you should write your phase-listener and configure it. Someone (like Ian ;)) says that putting logic into getters is good enough, but I don't think so (and not because logic into getters is always bad!). Anyway, your PhaseListener should contain code like if (viewId.equals("/page.xhtml")) { String paramId = context.getExternalContext().getRequestMap().get("id"); } That's pretty horrible. You also need to interact with your backing beans, and the code become quite a mess. All we need is an infrastructure upon this good mechanism. I hope JSF2.0 will define such architecture.
  29. Hi Everyone: JSF 2.0 seems to go a long way to delivering a widget library for Ajax development on Java. This makes me wonder about the bigger issues: I've been debating the Ajax versus Flash issue for the past year. Flash seems nice and compact but does not appear to deliver innovations beyond what Adobe dreams up. How do you test any of this stuff? There's no standards body issuing best practices, and the test tools know nothing about Ajax event models, data models, and protocols. Ajax development frameworks (Appcelerator, Backbase, Wavemaker, etc.) emerge as let-me-do-the-JavaScript automation for building Ajax applications. What are their advantages? I would love to know everyone's latest thinking on these? -Frank Cohen http://www.pushtotest.com
  30. U mean JSF 2.0 is not release YET?[ Go to top ]

    Wow, JSF 2.0 is still in Early Draft.. We started hearing about JSF 2.0 over two years ago, I can't believe is still not finalize/release yet. Nothing else positive to say anymore...
  31. Re: U mean JSF 2.0 is not release YET?[ Go to top ]

    Why the JCP let to Craig McClanahan be the Spec lead of JSF. It seems his style is a mess, Look at Struts and JSF, yuk. Also because Struts and JSF fault, now Rails and other alternatives are popular. Anyway I wish good luck to JSF team but ... If I'm you I will better contribute to another framework or create something better from scratch. Peace.
  32. Why the JCP let to Craig McClanahan be the Spec lead of JSF. It seems his style is a mess, Look at Struts and JSF, yuk. Also because Struts and JSF fault, now Rails and other alternatives are popular.

    Anyway I wish good luck to JSF team but ... If I'm you I will better contribute to another framework or create something better from scratch.

    Peace.
    Craig McClanahan is no more the spec lead, since 1.2(?).
  33. Why the JCP let to Craig McClanahan be the Spec lead of JSF. It seems his style is a mess, Look at Struts and JSF, yuk.
    Unlike with Struts, Craig did a great service to the community by not releasing JSF 1.x "in time" :-)
    Also because Struts and JSF fault, now Rails and other alternatives are popular.
    ASP.NET is defintely more popular than the brothers (i.e. Struts and JSF McClanahans), though the elder brother Struts was once the king in the Web application world.
  34. Unlike with Struts, Craig did a great service to the community by not releasing JSF 1.x "in time" :-)
    Hahaha Im agree. Do you do ASP.Net now? What are the benefits of it?.
  35. Do you do ASP.Net now? What are the benefits of it?.
    Under-engineered :-)
  36. Ed Burns, the JSF 2.0 co-spec lead (along with Roger Kitain), has pointed out the availability of the JSF 2.0 early draft review 2 specification. This incorporates early implementations of composite components and AJAX support. An ,implementation of the draft is also online, although the testing kit isn't complete.

    JSF 2.0 is a logical and necessary evolution of JSF; the only real question is whether it will be popular enough to compete against the more agile, less stable (specification-wise!) frameworks.
    Congratulations Ed! I'm glad to see this spec moving forward. I enjoyed our chat after your presentation at JSFOne and I while I haven't had a chance to review the JSF 2.0 spec in detail yet I was wondering, did my recommendation to include tags for JSF-generated HTML head and body content make it into the draft? If you recall the context of the discussion was on enabling a simplified UI development model for page designers using more atomic tags in the view to complement/as an alternative to tags that actually render the head or body tags. So in other words I am hoping to see something like h:headContent and h:bodyContent tags in addition to h:head and h:body if JSF 2.0 will include these. Also, what is the status on passing parameters in the EL? Will this make it into JSF 2.0? Is this issue covered by another JSR? Thanks for your excellent work on this specification. I appreciate that JSF 2.0 standardizes Ajax for JSF and maintains compatibility with previous versions of the framework. This will make it much easier for users to upgrade and avoids the pain associated with emergent framework design, broken compatibility, difficult upgrade paths, etc. At the same time, JSF's inherent extensibility guarantees it will be able to evolve and adapt to the needs of users in the future. JSF supports a balance between innovation and stability. I think critics of JSF should keep this in mind. Ian Hlavats JSFToolbox - Design JSF Pages in Dreamweaver Read my article on JSFCentral.com
  37. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    I have worked as Architect in company like IBM and Accenture. We have just finsished a big project(SOA in BI domain) using JSF1.2.9 + Seam + Rich Faces 3.2.1 + Facelets 1.1.14 + Fusion Charts(Charting Library). JSF1.2.9 is very stable and on 1 or 2 instance we faced issues, remember it is all open source so we can fix issues ourselves, just need some brain. Trust my words JSF has a great future!!!. Web development has to get component and even oriented. Don't think of ignoring JSF as JSP has no life left. Rich Faces has a good Ajax driven component library. Not even a single day I felt Ajax is complex. Rich Faces gives you good looking component. Facelets gives you power of developing templates and composite component. JSF 2.0 is in very right direction - with component authoring going to become easy and pending issues like Ajax and Skinning getting fixed. I am very confident about this framework future. Just club with Netbeans 6.5 and you will see the productivity enhancement in web development. Our pages don't have single line of logic ( not simple in JSP) and are full of AJAX (imp for WEB2.0). I have worked for years with ASP.net and other web frameworks. I will just summarize JSF is in very right direction and we just need to contribute to make it better. My wish list - Lot more sophisticated components like - Layout Managers, Advanced drill down grids, client-side validation framework, beautiful looking skins(richfaces does a good job, but then it cannot be applied to woodstock components, so skin compatibilty is must). JAVA FX needs to harvested for more rich behaviour(this is critical for future survival). FIJI - is very good for integrating with Flex charting. Things are going in right direction we all need to contribute.
  38. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    Trust my words JSF has a great future!!!. Web development has to get component and even oriented
    Why?? Why do you need re-construct a component tree on the submission? Don't you think representing all the morass of HTML markup as components and losing control over the markup is a bad thing? This is very much like Hibernate vs iBatis debate - loss of control over SQL Have you read points raised by RSF Authors? http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=JSF http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=JSFandRSFHistory We have tried RSF in one of our projects almost out of compulsion to do something different from Struts and avoid JSP. We had to give up on JSF + Rich faces + Facelets since our infrastructure is still WAS 5.1 , JDK 1.4.2. JSF 2 will take almost 4 more years ( in the next upgrade of WAS from 6 to 7) We used the AJAX capabilities of the 0.7.3 version whichi provided JSON data views that we could simply link up to Isomorphic's SmartClient ( free open source on the client side - consumes JSON) and it works nicely.
  39. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    I really don't understand if you are using WAS 5, then you don't have reason to blame JSF. It only requires server to support JSP 2+. Our project has implemented our 100 JSF pages and 20-30 CRUDs and full of charts. I really don't understand are you still using JSP ? JSF is supported on all appservers or patch for JSP 2 is available for many. Please consult good architect, he may help you. JSF2 is promising and does not require any new feature from app-server. I really doubt your technical inputs, please try some nightly builds of majorra and u will realize it works with Weblogic, JBOSS, Glassfish etc. I agree JSF start was not good, but now use JSF with Majorra 1.2.9 + Seam 2.x + Facelets 1.1.14 + Rich Faces 3.2.x. + Ajax4J Make good composite components using Facelets and use SEAM wisely with spring and Hibernate and your life will be very easy. I don't care if component tree is constructed or not as I never faced any issues with it. Portal 2 and WSRP stuff is in very common use for big enterprise projects and with JSF portal bridge, I cannot imagine people still using old technologies.
  40. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    I really don't understand if you are using WAS 5, then you don't have reason to blame JSF.

    It only requires server to support JSP 2+.

    Our project has implemented our 100 JSF pages and 20-30 CRUDs and full of charts.

    I really don't understand are you still using JSP ?

    JSF is supported on all appservers or patch for JSP 2 is available for many. Please consult good architect, he may help you.

    JSF2 is promising and does not require any new feature from app-server. I really doubt your technical inputs, please try some nightly builds of majorra and u will realize it works with Weblogic, JBOSS, Glassfish etc.

    I agree JSF start was not good, but now use JSF with Majorra 1.2.9 + Seam 2.x + Facelets 1.1.14 + Rich Faces 3.2.x. + Ajax4J

    Make good composite components using Facelets and use SEAM wisely with spring and Hibernate and your life will be very easy.

    I don't care if component tree is constructed or not as I never faced any issues with it.

    Portal 2 and WSRP stuff is in very common use for big enterprise projects and with JSF portal bridge, I cannot imagine people still using old technologies.
    I really don't understand are you still using JSP ?
    No we are not using JSP(s). We are using pure HTML templates with RDF:ID attributes ( similar to Tapestry and Wicket) that RSF supports. That is the big buy. If you want to reskin that is very convenient and mockups developed by business analysts are used as is. To do this in JSF you have to use two frameworks JSF and facelets As regards WAS 5.1 issue WAS 5.1 supports JSP 1.2 and Servlet 2.3 - We cannot use even the better version of JSF - i.e 1.1 as facelets requires JDK 1.5 RSF is a stateless framework that deals with templates and also provides JSOn integration with many popular AJAX toolkits - whereas JSF reconstructs prior state from either client or severside - that is one primary reason for bloat. Secondly there is no vying need to propagate events from browser to server backend ( another reason bloat), since AJAX toolkits can handle that better on the client side. People who have programmed with Struts / JSP all these years can consider RSF instead wasting the effort to learn JSF!! Reading RSF site reminds one of reading Rod Johnson's book of J2EE developmenet without EJB. History repeats! Sun and Sun certified architects have the lowest credibility and people who develop things like RSF have better credibility these days.
  41. Re: JSF 2.0 Early Draft Review 2 Available[ Go to top ]

    I don't want to read any body article, as i have confidence on my past experience, my implementations.
  42. A lot of ideas of JSF 2 already are in Tapestry 5 or Wicket, Why not adopt Tapestry 5 or Wicket as a standard and be done with the problem. I think already both Wicket and Tapestry 5 can work with SEAM so just get rid of JSF and plug Tapestry or Wicket in your projects.
  43. I have respect for all people in industry including RSF/JSF/Facelets/SEAM/etc. guys. By the way I am not SUN certified(anyways I respect them too.),I am IBM certified, Rational certifed SOA designer. I will summarize by saying JSF 2 is on right path.
  44. Certification's doesn't prove anything, you could cheat, just memorize the guide and with good luck and you could pass. Real programmers are that ones that have experience and already worked in many projects. So who the hell still care about certification's? Software changes every second, if you ware on the hardware or networking industry a certification works little better because it proves you know about the patterns of the device but it could change fast also. Maybe the only certification for software developers that still works is your university diploma because is where you learn the basics as algorithms and structures etc.
  45. Does it jump over page-based architecture for favor of pure-Ajax?