Discussions

News: Gavin seems to really dig JSF

  1. Gavin seems to really dig JSF (167 messages)

    Gavin King, in an interview with Dick Wall on JavaPosse, offers a set of strong points for JSF. Some of his statements say that JSF is a strong framework and that some of its bad press is noise from competing frameworks. What do you think?

    "What are the strong points of JSF?"

    Gavin King:
    "The rough ride JSF has been getting has been vastly exagerated. We can see a lot of adoption of JSF. Along with some noisy people who are promoting competing frameworks in fact. One of the things you need to when you need to see a technology that is really going to take off is to look how many people are screaming about it and saying how terrible it is. That is the case with Hibernate. It was the case wtih EJB3. It is the case with the organization I work for. You know there are number of people in the industry who are great negative indicators. When they hate something you know its real. And JSF is one of those things."

    ...

    "JSF is a fantastic model. It is very easy to use. Most of the critisim that is made of JSF is actually factually incorect. On these community sites that claim you can't build restful application with JSF. I mean it is total nonsense. It is not even remotely true."

    ...

    "When I came to look at JSF, I was casting around for a web framework to marry with EJB3. I was looking around and I was 'well let's start with what it is the spec. (JSF)'. And I was thinking it was going to be a steaming pile. (However), I found once I actually sat down and looked at it. It was working how I would think to design a (web) framework. When I used it, it was real easy to use and I think it is great."

    ...

    "It has some really key features. The interaction model between the view and the component model. The idea of freely binding components to the view is excellent. This is a very strong concept. Stronger than in a lot of previous frameworks."

    ...

    "I like the JSF templating. A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS."

    Check out more of this transcript at:

    http://jroller.com/page/RickHigh?entry=turns_out_gavin_king_is

    Threaded Messages (167)

  2. Gavin seems to really dig JSF[ Go to top ]

    Although I do not like JBoss and recently Gavin's rethorics I must agree with the most facts he said.
  3. Standards? Indicators?[ Go to top ]

    Hi everybody,

    One note about the talk about "Standards". "JSF" is not a standard by any means. It's a "Specification" nothing more.
    Standards are things like those provided by ISO. Even broad adoption isn't enough for the attribute "standard".

    When it comes to indicators that indicate anything (or nothing): It's strong indication for me to keep my eyes wide open for - sometimes better - alternatives to hibernate, jsf, spring and...when a jbossie pushes his ideas.
    My idea about frameworks is: Make up your mind. Make it up yourself by looking into the frameworks. Don't get fooled by anyone. And then decide carefully if the framwork suits your actual needs. I'm great fan of doing daos myself if I need lightweightness and speed, or debuggability...and if I know that never in my life I would need to support 20 different databases...

    If Gavin want's to dig, why not give him a tool like a spade (standardiesed by tool time and binford) or something similar, to dig in jboss.
  4. Standards? Indicators?[ Go to top ]

    Hi everybody,One note about the talk about "Standards". "JSF" is not a standard by any means. It's a "Specification" nothing more.Standards are things like those provided by ISO. Even broad adoption isn't enough for the attribute "standard".

    I think we're playing word games now. Whether you call it a "standard" or "just a specification", the reality is the same: It has gone through a vetting process and the result is a specification that anyone can implement and that various implementations should provide interoperability among.

    Besides, the ISO is not any more of a real standard, because previous to the ISO there was no ISO to make ISO into a standard, and thus it is just as self-referential as anything else.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  5. Wordgames - not to bad[ Go to top ]

    Wordgames: If you think so.
    My opinion: Don't let them sell you a x for an u...And it starts right away with pumping (pimping) up things to make them look bigger than they are. This was just meant as an introduction for my point to choose carefully what you need for your projects...

    Hm, and I can't see why the International Standard Organisation is not providing Standards anymore and whether the notion of being "self-refrential" has something to to with my point...

    Cheers,
    Peter
  6. Wordgames - not to bad[ Go to top ]

    Wordgames: If you think so.My opinion: Don't let them sell you a x for an u...And it starts right away with pumping (pimping) up things to make them look bigger than they are.

    Well, my view is that a standard/specification (whatever you want to call it) from the JCP is obviously a big thing anyway. It is the result of possibly years of work by an expert team and is then voted on by a panel of significant people and organisations. No matter what you think of it, it is very significant.
  7. Wordgames: If you think so.My opinion: Don't let them sell you a x for an u...And it starts right away with pumping (pimping) up things to make them look bigger than they are.
    Well, my view is that a standard/specification (whatever you want to call it) from the JCP is obviously a big thing anyway. It is the result of possibly years of work by an expert team and is then voted on by a panel of significant people and organisations. No matter what you think of it, it is very significant.

    Standards are good. That is why there are so many of them (often competing ones at that).

    To be honest, I don't care if JSF is a standard. What I do care about is that there is a lot of tool support and component libraries (not to mention inovation Facelets). Of course being a standards helps with the above. However there are plenty of standards that never really see any adoption (COS Directory comes to mind).

    Hibernate is one that sees a lot of adoption even without being a standard. Struts is another one that enjoys that status.

    The adoption (of JSF) has started, but it is no where near where I think it should be after nearly two years. But then again patience has never been my strong point.

    There is a lot going on with JSF and its use seems to growing. (I guess this by the amount of job postings and blogs about it.)

    I think one problem with adoption was the huge investment folks put into learning and adopting Struts. It was just hitting critical mass when JSF started to come out.

    JSF is such a better solution than Struts, yet that is what most shops are using.
  8. Hibernate is one that sees a lot of adoption even without being a standard. Struts is another one that enjoys that status.

    In my experience there is a real benefit in being in a position to tell vendor that you need better support or you will switch to a competitor....

    One of the reasons I used JDO rather than Hibernate years ago was because I had certain uses for ORM that Hibernate (according to certain posts on their forums) did not recommend it should be used for. I turned to JDO because vendors were competing to optimise their implementations for the sorts of uses I had in mind. They could compete because they were implementing the same spec.
    The adoption (of JSF) has started, but it is no where near where I think it should be after nearly two years.

    I think that there are good reasons why JSF has only recently started to take off significantly. Firstly, the initial release was distinctly buggy and did not integrate at all well with existing approaches - even with JSP, which was supposed to be the default rendering technology. Secondly....
    I think one problem with adoption was the huge investment folks put into learning and adopting Struts.

    This is the key point.
    It was just hitting critical mass when JSF started to come out.JSF is such a better solution than Struts, yet that is what most shops are using.

    I guess for many existing shops, struts is just good enough. I think the increasing range and quality of components for JSF will change this situation.
  9. Hibernate is one that sees a lot of adoption even without being a standard. Struts is another one that enjoys that status.
    In my experience there is a real benefit in being in a position to tell vendor that you need better support or you will switch to a competitor....One of the reasons I used JDO rather than Hibernate years ago was because I had certain uses for ORM that Hibernate (according to certain posts on their forums) did not recommend it should be used for. I turned to JDO because vendors were competing to optimise their implementations for the sorts of uses I had in mind. They could compete because they were implementing the same spec.
    The adoption (of JSF) has started, but it is no where near where I think it should be after nearly two years.
    I think that there are good reasons why JSF has only recently started to take off significantly. Firstly, the initial release was distinctly buggy and did not integrate at all well with existing approaches - even with JSP, which was supposed to be the default rendering technology. Secondly....
    I think one problem with adoption was the huge investment folks put into learning and adopting Struts.
    This is the key point.
    It was just hitting critical mass when JSF started to come out.JSF is such a better solution than Struts, yet that is what most shops are using.
    I guess for many existing shops, struts is just good enough. I think the increasing range and quality of components for JSF will change this situation.

    JSF was certainly not super robust when it first came out, but I was able to write apps with it right away and still found it more productive than Struts. Things have improved. The ideas were solid and the implementations (thanks a lot to MyFaces) improved.
  10. Wordgames - not to bad[ Go to top ]

    Wordgames: If you think so.My opinion: Don't let them sell you a x for an u...And it starts right away with pumping (pimping) up things to make them look bigger than they are.

    I'm not a fan of JSF, but I'm not an "opponent" of it either. I'd like to learn more about it technically, and until then it's hard to know how good/bad it is for a particular use case.

    BTW, one man's pimping is another man's marketing ;-)
    Hm, and I can't see why the International Standard Organisation is not providing Standards anymore and whether the notion of being "self-refrential" has something to to with my point...

    My point (intended to be somewhat humorous) is that the JCP is really no more or less self-referential in its standards-making capability than the ISO.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  11. +1[ Go to top ]

    What Gavin said is like the light at the end of the tunnel for me, I heard that using JSF is horible but after using it my self and XP-ing many of it's features I think it's a great framework, Thanx Gavin.
  12. +1[ Go to top ]

    Interaction models of other web component frameworks seam freaky compared to JSF's one.
  13. +1[ Go to top ]

    Interaction models of other web component frameworks seam freaky compared to JSF's one.
    Were you trying to be punny? :)
  14. every joke has a bit of truth[ Go to top ]

    SUBJ
  15. punny[ Go to top ]

    Interaction models of other web component frameworks seam freaky compared to JSF's one.
    Were you trying to be punny? :)

    No not really. That was an accident. I ran it through a spellchecker, but a spellchecker can't detect brain malfunctions.
  16. Of course he will say JSF is good[ Go to top ]

    He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?

    His analysis of why he doesn't like Tapestrys straight HTML template files are rather idiotic. But then again, he has credibility when it comes to object-relational mapping, not web frameworks. He is just a shmoe like you and me in that area.
  17. Of course he will say JSF is good[ Go to top ]

    He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?

    This is strange reasoning. Why would he have started Seam unless he thought JSF was a good framework?
  18. Of course he will say JSF is good[ Go to top ]

    He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?
    This is strange reasoning. Why would he have started Seam unless he thought JSF was a good framework?

    Mats was using a logically identical argument to that of Gavin's in his interview - if you invalidate one of the arguments on formal grounds, you invalidate the other. My pure guess would be that that exactly was Mats' point.
  19. What I'm saying is that him saying so isn't surprising. It would be very very strange if he didn't say he liked JSF.
  20. What I'm saying is that him saying so isn't surprising. It would be very very strange if he didn't say he liked JSF.

    My impression was that you were saying that he liked JSF not because of any particular advantages to the framework itself, but because it is what he would have to say that to push Seam.

    It was also my impression that you were implying that even if he liked JSF, it was irrelevant because he had made an 'idiotic analysis' of one aspect of Tapestry, and he is 'just a shmoe' in terms of web frameworks.
  21. Of course he will say JSF is good[ Go to top ]

    He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?
    This is strange reasoning. Why would he have started Seam unless he thought JSF was a good framework?
    +1 I thought the same thing. Some people have to find an ulterior motive in everything.
  22. If Gavin was pushing a stock, wouldn't we notice that he is fully vested in JSF? It is OK to push a stock or technology even if you have conflicts of interests, of course, but ignoring them as a listener would be just totally idiotic.
  23. Ken Lay has left the building[ Go to top ]

    If Gavin was pushing a stock, wouldn't we notice that he is fully vested in JSF? It is OK to push a stock or technology even if you have conflicts of interests, of course, but ignoring them as a listener would be just totally idiotic.

    Yeah, I hear your point, but it seems only applicable to the people responding without reading the article.

    If you've read the article and interview where is the conflict of interest? Everything seems on the up and up to me:
    1) Gavin wanted a UI framework to marry to EJB3
    2) Since he likes EJB3 he would probably want to stick to other J2EE standards - JSF is one
    3) He explores the JSF standard and likes what he sees enough to make a framework implementing the standard
    4) He does interviews promoting his framework and backing up his decisions with some facts and opinions

    I don't see any sneekiness or anything behind the scenes here. The whole point of the interview is based on the fact that he was describing why he felt Seam was needed. A conflict of interest would be him praising the merits of JSF and Seam without disclosing that it was his project.
  24. But then again, he has credibility when it comes to object-relational mapping, not web frameworks. He is just a shmoe like you and me in that area.

    Gavin King's technical point of view is one I will always respect seeing what he produced in the last couple of years, even if it wasn't in the web tier.
  25. Kevin is so Smart[ Go to top ]

    Thank you so much Kevin. JSF is a strong framework. I've been wokking on JSF since early 2004. I build a big Project and it's really working fine. I agree with some of you who have/had some difficulties using it (The learning curve is little hard), But patient programmers will find it worth working on JSF.

    The Best of the best is to go JSF/Spring/Hibernate. For sure you will programming.

    thanks
  26. Kevin is so Smart[ Go to top ]

    Thank you so much Kevin. JSF is a strong framework. I've been wokking on JSF since early 2004. I build a big Project and it's really working fine. I agree with some of you who have/had some difficulties using it (The learning curve is little hard), But patient programmers will find it worth working on JSF.The Best of the best is to go JSF/Spring/Hibernate. For sure you will programming.thanks

    I've worked on several production apps since its release. It is a very productive environment, and I never use the drag&drop tools.

    My current stack is Facelets/JSF/Spring/Hibernate. Facelets add a whole new dimension of view reuse. You gotta try it.

    http://jroller.com/page/RickHigh?entry=facelets_fits_jsf_like_a

    I just started digging into Seam. The trick for me will be "what is the best way to combine Seam and Spring". Seam shoots at the heart of what people use Spring for.... When do you use which? I am a big Spring fan, but Seam is compelling enough for me to look into EJB3.
  27. Kevin is so Smart[ Go to top ]

    I've been messing with Facelets since reading the "fits like a glove.." article, and I have to agree with you, it compliments JSF very nicely. I've been converting (read removing) my UIComponent/Tag classes to composition components.. what a nice change that is. For those of you who DO like JSF you really need to try Facelets.

    http://www-128.ibm.com/developerworks/java/library/j-facelets/

    Oh, and I agree with Kevin's comments about JSF. If you want a second opinion you can read the comments on JSF by the creator of struts too (yeah I know he works for Sun now so everything he says is suspect. whatever.)
  28. Kevin is so Smart[ Go to top ]

    Who is 'Kevin'? ;)
  29. Kevin is so Smart[ Go to top ]

    Sorry Gavin.

    I suggest How Wonderfull the world will be if java community concentrate it's enegy on JSF ?.
  30. Kevin is so Smart[ Go to top ]

    Who is 'Kevin'? ;)
    Good question... I have no idea. It was part of a title where the body made no connection to the title (to me).
  31. Kevin is so Smart[ Go to top ]

    I've been messing with Facelets since reading the "fits like a glove.." article, and I have to agree with you, it compliments JSF very nicely. I've been converting (read removing) my UIComponent/Tag classes to composition components.. what a nice change that is. For those of you who DO like JSF you really need to try Facelets.http://www-128.ibm.com/developerworks/java/library/j-facelets/Oh, and I agree with Kevin's comments about JSF. If you want a second opinion you can read the comments on JSF by the creator of struts too (yeah I know he works for Sun now so everything he says is suspect. whatever.)

    I agree. Please read the article. I found Facelets to be refreshing and exciting. I saw in the Seam documentation that Gavin thinks the same.

    Good job Jacob H. et al. You guys rock!
  32. He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?
    Doh! But then again, they must had a reason to choose JSF as a base spec for Seam at the first place.
    His analysis of why he doesn't like Tapestrys straight HTML template files are rather idiotic.
    Afaik, Tapestry and Wicket define stuff in two places: HTML template and Java code. These two definitions must correspond to each other and the only way to see how well they correspond is only in runtime. Defining stuff in one place is simpler. Binding to arbitrary properties of arbitrary beans (JSF, Struts, plain JSP) is simpler than building a hierarchy of Java classes that reflects component structure (Wicket). In this respect it would be interecting to hear how Wicket and Tapestry implement ajaxified in-place update where DOM structure of a page can be changed. Do they require to modify the structure of Java classes (not the relationship of instantiated objects) on the server side as well?

    Gavin is totally right about CSS, it is 2006 after all. Go check out the css zen garden.
  33. Binding to arbitrary properties of arbitrary beans (JSF, Struts, plain JSP) is simpler than building a hierarchy of Java classes that reflects component structure (Wicket).

    It's a tradeoff. JSF is stronger if you have to often change your hierarchy. Wicket is stronger when it comes to component/ model interaction.
    In this respect it would be interecting to hear how Wicket and Tapestry implement ajaxified in-place update where DOM structure of a page can be changed. Do they require to modify the structure of Java classes (not the relationship of instantiated objects) on the server side as well?

    With Wicket you have to change the relationship of the instantiated objects. E.g. you replace Panel x with Panel y. Btw, such AJAX support is already in place for Wicket. You can check it out today if you are interested (though you're probably bussy with your own framework ;))
    Gavin is totally right about CSS, it is 2006 after all. Go check out the css zen garden.

    So why can't you have clean templates that work with CSS? What about the argument that if your HTML isn't messed up with foreign tags, it is just easier to read, maintain, etc?
  34. Of course he will say JSF is good[ Go to top ]

    Binding to arbitrary properties of arbitrary beans (JSF, Struts, plain JSP) is simpler than building a hierarchy of Java classes that reflects component structure (Wicket).
    It's a tradeoff. JSF is stronger if you have to often change your hierarchy. Wicket is stronger when it comes to component/ model interaction.

    I should've been more clear on this point in relation to JSF/Seam. Since JSF's component model isn't tied by reference or otherwise to the model tier, Seam is able freely manipulate the lifecycles of model instances without modification to all the rest of JSF. This can even occur alongside support with Spring (scary, I know). As I said in my original post, I have no doubt that frameworks, like Wicket, could be used with Seam, I'm just not sure it would be as easy or as agnostic.
  35. weekly JSF promition[ Go to top ]

    So Rick, Jacob, Steve, ... already bussy writing your next JSF promotion for TSS/ JavaLobby? It's almost like it needs a bit of promotion :)
  36. weekly JSF promition[ Go to top ]

    So Rick, Jacob, Steve, ... already bussy writing your next JSF promotion for TSS/ JavaLobby? It's almost like it needs a bit of promotion :)

    Not until we have a fix for better state saving ;-)
  37. weekly JSF promition[ Go to top ]

    So Rick, Jacob, Steve, ... already bussy writing your next JSF promotion for TSS/ JavaLobby? It's almost like it needs a bit of promotion :)

    I don't know nearly enough about it to promote it well, even assuming I wanted to.
  38. weekly JSF promition[ Go to top ]

    So Rick, Jacob, Steve, ... already bussy writing your next JSF promotion for TSS/ JavaLobby? It's almost like it needs a bit of promotion :)

    I write about the stuff I use. I have nothing to promote. I did not write Facelets. I am not on the JSF spec. group.

    If I were using Tapestry or Wicket, I'd probably write about that.
  39. Binding to arbitrary properties of arbitrary beans (JSF, Struts, plain JSP) is simpler than building a hierarchy of Java classes that reflects component structure (Wicket).
    It's a tradeoff. JSF is stronger if you have to often change your hierarchy. Wicket is stronger when it comes to component/ model interaction.
    It just seems too complicated to me to always keep class/object hierarchy in sync with a page. On the other hand, JSF is too complex for me as well :)
    In this respect it would be interecting to hear how Wicket and Tapestry implement ajaxified in-place update where DOM structure of a page can be changed. Do they require to modify the structure of Java classes (not the relationship of instantiated objects) on the server side as well?
    With Wicket you have to change the relationship of the instantiated objects. E.g. you replace Panel x with Panel y. Btw, such AJAX support is already in place for Wicket. You can check it out today if you are interested (though you're probably busy with your own framework ;))
    I see. I might take a look but you guessed correctly that I am busy with my own... well, just a library :) I hope Wicket gets better recognition though.
    Gavin is totally right about CSS, it is 2006 after all. Go check out the css zen garden.
    So why can't you have clean templates that work with CSS?
    Of course you can. But the possibility to use CSS in both JSF and Wicket does not make Wicket better or JSF worse. I just meant that CSS *is* the way to go with markup.
    What about the argument that if your HTML isn't messed up with foreign tags, it is just easier to read, maintain, etc?
    I guess that JSF is not supposed to contain any HTML, only JSF tags. Whatever is rendered depends on renderer, so there should be no HTML to mess. In relation to "HTML is easier to read", this is only because you already know HTML. I guess that JSF is not supposed to be read, the same as Delphi's DFMs are not supposed to be read. For me, JSF page is more like a dialog window resource definition and I think that in some way it is similar to XAML.

    ---
    Michael Jouravlev
    JSP Controls: Create web components with little more than bare JSP
  40. I guess that JSF is not supposed to contain any HTML, only JSF tags. Whatever is rendered depends on renderer, so there should be no HTML to mess. In relation to "HTML is easier to read", this is only because you already know HTML. I guess that JSF is not supposed to be read, the same as Delphi's DFMs are not supposed to be read. For me, JSF page is more like a dialog window resource definition and I think that in some way it is similar to XAML.

    Bingo. Maintainability is instead promoted via encapsulation and reuse with components or compositions and by staying model and controller agnostic.
  41. I hope Wicket gets better recognition though.

    We're doing pretty good actually. We are getting to a point where it is hard keep up with feature requests etc. We're deliberately laying low to protect ourselves ;) We'll do some more promoting when Wicket In Action comes out, and some of the features we are working on right now are done.
    I guess that JSF is not supposed to contain any HTML, only JSF tags. Whatever is rendered depends on renderer, so there should be no HTML to mess. In relation to "HTML is easier to read", this is only because you already know HTML. I guess that JSF is not supposed to be read, the same as Delphi's DFMs are not supposed to be read. For me, JSF page is more like a dialog window resource definition and I think that in some way it is similar to XAML.

    Yeah, that's certainly a valid way to look at it. I guess any further discussion on that would result in a fruitless debate on elegance and taste :)
  42. Binding to arbitrary properties of arbitrary beans (JSF, Struts, plain JSP) is simpler than building a hierarchy of Java classes that reflects component structure (Wicket).
    It's a tradeoff. JSF is stronger if you have to often change your hierarchy. Wicket is stronger when it comes to component/ model interaction.
    In this respect it would be interecting to hear how Wicket and Tapestry implement ajaxified in-place update where DOM structure of a page can be changed. Do they require to modify the structure of Java classes (not the relationship of instantiated objects) on the server side as well?
    With Wicket you have to change the relationship of the instantiated objects. E.g. you replace Panel x with Panel y. Btw, such AJAX support is already in place for Wicket. You can check it out today if you are interested (though you're probably bussy with your own framework ;))
    Gavin is totally right about CSS, it is 2006 after all. Go check out the css zen garden.
    So why can't you have clean templates that work with CSS? What about the argument that if your HTML isn't messed up with foreign tags, it is just easier to read, maintain, etc?

    All I know about Wicket is what I've read via the documentation provided. It seems verbose compared to JSF. If Wicket is better, I don't think you have made you case as to why and how. This is not to say that it is or that it isn't but the case has not (in my mind) been made conclusively.
  43. Of course he will say JSF is good[ Go to top ]

    +1 Excellent reply
  44. that's funny[ Go to top ]

    He is pushing his JSF based framework called SEAM! It would look rather odd if he dissed JSF, wouldn't it?His analysis of why he doesn't like Tapestrys straight HTML template files are rather idiotic. But then again, he has credibility when it comes to object-relational mapping, not web frameworks. He is just a shmoe like you and me in that area.
  45. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).

    I know you shouldn't have to explain a joke, but what pun?
  46. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).
    I know you shouldn't have to explain a joke, but what pun?
    I am going to venture a guess and go with:

    Gavin really gets/likes (digs - verb) JSF.
    Others say bad/sarcastic things (digs -noun) about JSF.
  47. What pun? (that's not it)[ Go to top ]

    Gavin seems to really dig JSF (pun intended).
    I know you shouldn't have to explain a joke, but what pun?
    I am going to venture a guess and go with:Gavin really gets/likes (digs - verb) JSF.Others say bad/sarcastic things (digs -noun) about JSF.


    Maybe my humor was too subtle and dry.... Try again. It is a lot less brainy than that I assure you.
  48. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).

    I know you shouldn't have to explain a joke, but what pun?

    I am going to venture a guess and go with:

    Gavin really gets/likes (digs - verb) JSF.
    Others say bad/sarcastic things (digs -noun) about JSF.

    Gavin seems to really dig JSF ..

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  49. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).
    I know you shouldn't have to explain a joke, but what pun?
    I am going to venture a guess and go with:Gavin really gets/likes (digs - verb) JSF.Others say bad/sarcastic things (digs -noun) about JSF.
    Gavin seems to really dig JSF ..Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Stupid forest! I couldn't see the tree.
  50. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).
    I know you shouldn't have to explain a joke, but what pun?
    I am going to venture a guess and go with:Gavin really gets/likes (digs - verb) JSF.Others say bad/sarcastic things (digs -noun) about JSF.
    Gavin seems to really dig JSF ..Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    I thought it was obvious. Perhaps it was too simple.
  51. What pun?[ Go to top ]

    Gavin seems to really dig JSF (pun intended).
    I know you shouldn't have to explain a joke, but what pun?
    I am going to venture a guess and go with:Gavin really gets/likes (digs - verb) JSF.Others say bad/sarcastic things (digs -noun) about JSF.
    Gavin seems to really dig JSF ..Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    I thought it was obvious. Perhaps it was too simple.
    I guess I am partial to homographs as opposed to homophones.

    For those who need explaination - http://teenwriting.about.com/od/glossar1/g/GlosHomonym.htm
  52. What pun?[ Go to top ]

    I guess I am partial to homographs as opposed to homophones.

    Good. We don't want homophonia around here.
  53. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF? He blindly chose JSF because it's a spec (a standard). I wonder if he really genuinely looked deeper into one of the proven and powerful web frameworks of our time such as Wicket, Tapestry or Echo2.
    What most people care about is a framework that makes them productive and has a nice concept behind it. Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.

    J.
  54. How can you suppose that[ Go to top ]

    The guy has proven in the past he was able to go out of the standard by creating Hibernate, which then became a standard itself (mainly because he tought EJB was a "bad" development standart). But if you think the standard is good, there's no reason to create a new one (the best idea is to try to propose some improvements if necessary).

    Joz
  55. How can you suppose that[ Go to top ]

    The guy has proven in the past he was able to go out of the standard by creating Hibernate, which then became a standard itself (mainly because he tought EJB was a "bad" development standart). But if you think the standard is good, there's no reason to create a new one (the best idea is to try to propose some improvements if necessary). Joz

    Man, be smart for once. This guy is now working for a company that survives by implementing specs and release them under open source. Or is that just a coincidence?

    J
  56. How can you suppose that[ Go to top ]

    The guy has proven in the past he was able to go out of the standard by creating Hibernate, which then became a standard itself (mainly because he tought EJB was a "bad" development standart). But if you think the standard is good, there's no reason to create a new one (the best idea is to try to propose some improvements if necessary). Joz
    Man, be smart for once. This guy is now working for a company that survives by implementing specs and release them under open source. Or is that just a coincidence?J
    I know where you can buy aluminum foil helmets for real cheap,. ;)
  57. How can you suppose that[ Go to top ]

    The guy has proven in the past he was able to go out of the standard by creating Hibernate, which then became a standard itself (mainly because he tought EJB was a "bad" development standart). But if you think the standard is good, there's no reason to create a new one (the best idea is to try to propose some improvements if necessary). Joz
    Man, be smart for once. This guy is now working for a company that survives by implementing specs and release them under open source. Or is that just a coincidence?J
    I know where you can buy aluminum foil helmets for real cheap,. ;)

    Mark, You made my Orange Juice come through my nose. Too funny! Thanks.
  58. How can you suppose that[ Go to top ]

    Mark, You made my Orange Juice come through my nose. Too funny! Thanks.
    You're welcome. Glad I finally got one to work. But you can thank whomever mentioned this same thing in another thread.
  59. How can you suppose that[ Go to top ]

    Mark, You made my Orange Juice come through my nose. Too funny! Thanks.
    You're welcome. Glad I finally got one to work. But you can thank whomever mentioned this same thing in another thread.

    Do you mean the guy who said (in the Facelets thread):
    Everything is a conspiracy these days. It is one thing to be skeptical. It is quite another to live in a closet with alluminum foil on your head to block the evil gamma rays that the government is using to control your brain.

    Make a point why you feel JSF and/or Facelets sucks and then see how quickly Jacob and/or Steve (and/or Kito) rip it apart.

    I'd go with the conspiracy theory if I was you too. It is much safer to do that than opine about the technology where you will get shredded.

    So let me get this straight you don't like JSF and you don't like Faclets. So what do you like?

    I am sure there are not shortcommings or tradeoffs with it. eh?

    I wonder who said that. He seems a bit angry. He needs to chill.
  60. To Rick H.[ Go to top ]

    Mark, You made my Orange Juice come through my nose. Too funny! Thanks.
    You're welcome. Glad I finally got one to work. But you can thank whomever mentioned this same thing in another thread.
    Do you mean the guy who said (in the Facelets thread):
    Everything is a conspiracy these days. It is one thing to be skeptical. It is quite another to live in a closet with alluminum foil on your head to block the evil gamma rays that the government is using to control your brain.Make a point why you feel JSF and/or Facelets sucks and then see how quickly Jacob and/or Steve (and/or Kito) rip it apart.I'd go with the conspiracy theory if I was you too. It is much safer to do that than opine about the technology where you will get shredded.So let me get this straight you don't like JSF and you don't like Faclets. So what do you like?I am sure there are not shortcommings or tradeoffs with it. eh?
    I wonder who said that. He seems a bit angry. He needs to chill.

    Rick, you have a wicket, I mean a wicked, sense of humour..! I like, I like. Don't think I wasn't paying attention! :-)

    The only problem is that you made my Windex-coloured Gatorade come out through my nose!

    Frederic
  61. How can you suppose that[ Go to top ]

    I wonder who said that. He seems a bit angry. He needs to chill.
    Yes. Quite a nut-job. I hear he has quite a collection of "The Catcher in the Rye". (google that and "Mel Gibson")
  62. How can you suppose that[ Go to top ]

    I wonder who said that. He seems a bit angry. He needs to chill.
    Yes. Quite a nut-job. I hear he has quite a collection of "The Catcher in the Rye". (google that and "Mel Gibson")

    Good one.
  63. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF?

    I care, I respect his contributions to the Java world and I really like to know what people like him, Rod Johnson, ... you name them, think about some products.
    Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.J.

    You can read mind? And by the way, yeah he liked so much EJB2 that he developped Hibernate... If you don't agree with him and you don't like JSF, it is your choice but stop spreading false statements like that. I'm tired of this anti-spec attitude.
  64. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF?
    I care, I respect his contributions to the Java world and I really like to know what people like him, Rod Johnson, ... you name them, think about some products.
    Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.J.
    You can read mind? And by the way, yeah he liked so much EJB2 that he developped Hibernate... If you don't agree with him and you don't like JSF, it is your choice but stop spreading false statements like that. I'm tired of this anti-spec attitude.

    Ok, Gavin would tell you JBoss is the most revolutionary and best app server on the planet. From your narrow mindedness I can say for sure you'll take his word for it. Because of his great contribution to the Java community.
    In the interview he says he chose JSF because it's a spec. My question is did he spend equal amount of time and effort on Wicket, Tapestry or Echo2 before drawing his conclusion? From this interview it doesn't seem so. And that's what worries me.

    J
  65. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF?
    I care, I respect his contributions to the Java world and I really like to know what people like him, Rod Johnson, ... you name them, think about some products.
    Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.J.
    You can read mind? And by the way, yeah he liked so much EJB2 that he developped Hibernate... If you don't agree with him and you don't like JSF, it is your choice but stop spreading false statements like that. I'm tired of this anti-spec attitude.
    Ok, Gavin would tell you JBoss is the most revolutionary and best app server on the planet. From your narrow mindedness I can say for sure you'll take his word for it.

    That's your call again. I say I really respect his opinions and will always enjoy reading it. I am not saying I am blindy following his opinion.

    Why do you think everyone follow something blindy? I looked at Tapestry but I prefer JSF from a technical point of view and also because the community around it is biger (probably has to do because it is a spec :)).
  66. So who cares?[ Go to top ]

    My question is did he spend equal amount of time and effort on Wicket, Tapestry or Echo2 before drawing his conclusion? From this interview it doesn't seem so. And that's what worries me.J

    Yes, he did spend time looking at Tapestry. Wicket would run into the same problems for the reason of not exactly having full Model/View separation. Again, we could go back and forth on the validity of that point, but two things: JSF has Model/View separation such that it's extremely easy to drop in solutions like Seam, Shale, or your own controller. Secondly, I know that Seam could be used with other frameworks down the road, maybe not as easily, but I'm sure it's on the table.
  67. So who cares?[ Go to top ]

    My question is did he spend equal amount of time and effort on Wicket, Tapestry or Echo2 before drawing his conclusion? From this interview it doesn't seem so. And that's what worries me.J
    Yes, he did spend time looking at Tapestry. Wicket would run into the same problems for the reason of not exactly having full Model/View separation. Again, we could go back and forth on the validity of that point, but two things: JSF has Model/View separation such that it's extremely easy to drop in solutions like Seam, Shale, or your own controller. Secondly, I know that Seam could be used with other frameworks down the road, maybe not as easily, but I'm sure it's on the table.

    Well you could go the other road as well, the Trails developer s went the Tapestry road, because they liked Tapestry more than JSF.

    But I think in the end it is good that every major component based app framework will have its own RAD framework people can use to hammer out applications quickly, no matter being it Trails or Seam.

    Btw. pure action based frameworks are out of the game (as the Trails developers already stated) for now in this area of framework games.
  68. So who cares?[ Go to top ]

    Wicket would run into the same problems for the reason of not exactly having full Model/View separation.

    Say what? Wicket hides the model behind an locator interface. You are free to plug any model you like and I am already doing automated SEAM like validations without having the need for that extra framework.

    If you don't want a JSF thread to be stolen by 'noisy people who are promoting competing frameworks' you might want to consider not talking about those competing frameworks. And if you do, please make sure what you tell is true.
  69. So who cares?[ Go to top ]

    Wicket would run into the same problems for the reason of not exactly having full Model/View separation.
    Say what? Wicket hides the model behind an locator interface. You are free to plug any model you like and I am already doing automated SEAM like validations without having the need for that extra framework.If you don't want a JSF thread to be stolen by 'noisy people who are promoting competing frameworks' you might want to consider not talking about those competing frameworks. And if you do, please make sure what you tell is true.

    Yes, but I think Michael did an excellent job of elaborating a bit more on the issue: http://www.theserverside.com/news/thread.tss?thread_id=39214#202356
  70. So who cares?[ Go to top ]

    Yes, but I think Michael did an excellent job of elaborating a bit more on the issue

    I was reacting to
    Wicket would run into the same problems for the reason of not exactly having full Model/View separation.

    Which is just not true. I can't see how it could be seperate more. The models are first class citizens and can be bound in any hierarchy at any time you want. If you really would want to do it e.g. by reading expressions from attribute values you could do that too, if that's what you mean.

    And
    Yes, but I think Michael did an excellent job of elaborating a bit more on the issue

    He was telling half of the story. Defining and moving around is easier. Component and model interaction is harder.
  71. So who cares?[ Go to top ]

    Wicket would run into the same problems for the reason of not exactly having full Model/View separation.
    Say what? Wicket hides the model behind an locator interface. You are free to plug any model you like and I am already doing automated SEAM like validations without having the need for that extra framework.If you don't want a JSF thread to be stolen by 'noisy people who are promoting competing frameworks' you might want to consider not talking about those competing frameworks. And if you do, please make sure what you tell is true.
    'noisy people who are promoting competing frameworks'

    I don't think Gavin was talking about you or Wicket when he said that. For that matter, I don't think he was talking about Howard or Tapestry either.

    I suspect he was talking about some of the WebWork folks. I bet he does not care to clarify.
  72. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF? He blindly chose JSF because it's a spec (a standard). I wonder if he really genuinely looked deeper into one of the proven and powerful web frameworks of our time such as Wicket, Tapestry or Echo2.What most people care about is a framework that makes them productive and has a nice concept behind it. Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.J.

    Blindly?
    "When I came to look at JSF, I was casting around for a web framework to marry with EJB3. I was looking around and I was 'well let's start with what it is the spec. (JSF)'. And I was thinking it was going to be a steaming pile. (However), I found once I actually sat down and looked at it. It was working how I would think to design a (web) framework. When I used it, it was real easy to use and I think it is great." -- G. King

    That does not sound blind to me.... Eyes wide open... expecting the worse more like it.
    I wonder if he really genuinely looked deeper into one of the proven and powerful web frameworks of our time such as Wicket, Tapestry or Echo2.

    I have looked at a few at great length. I choose JSF. Thanks.
  73. So who cares?[ Go to top ]

    Rick,

    Examine the quote below from Gavin't interview yourself:
    "When I came to look at JSF, I was casting around for a web framework to marry with EJB3. I was looking around and I was 'well let's start with what it is the spec. (JSF)'. And I was thinking it was going to be a steaming pile. (However), I found once I actually sat down and looked at it. It was working how I would think to design a (web) framework. When I used it, it was real easy to use and I think it is great." -- G. King

    So he says he started with the Spec. Did he go to look deeper into other frameworks or he started and stopped by the spec product just because it's a spec? It worries me that's the case.

    J
  74. So who cares?[ Go to top ]

    Rick,Examine the quote below from Gavin't interview yourself:
    "When I came to look at JSF, I was casting around for a web framework to marry with EJB3. I was looking around and I was 'well let's start with what it is the spec. (JSF)'. And I was thinking it was going to be a steaming pile. (However), I found once I actually sat down and looked at it. It was working how I would think to design a (web) framework. When I used it, it was real easy to use and I think it is great." -- G. King
    So he says he started with the Spec. Did he go to look deeper into other frameworks or he started and stopped by the spec product just because it's a spec? It worries me that's the case.J

    If you listen to the interview, you will note that he looked into Tapestry.
  75. So who cares?[ Go to top ]

    If you listen to the interview, you will note that he looked into Tapestry.

    Probably with less effort and time because Tapestry is not a spec. I certainly believe if had, he would have chosen the REAL component oriented framework. Maybe he did. But who knows, company direction might have influenced him to choose otherwise.

    J.
  76. So who cares?[ Go to top ]

    If you listen to the interview, you will note that he looked into Tapestry.
    Probably with less effort and time because Tapestry is not a spec. I certainly believe if had, he would have chosen the REAL component oriented framework. Maybe he did. But who knows, company direction might have influenced him to choose otherwise.

    J.

    LOL, are you not reading my replies?
  77. So who cares?[ Go to top ]

    If you listen to the interview, you will note that he looked into Tapestry.
    Probably with less effort and time because Tapestry is not a spec. I certainly believe if had, he would have chosen the REAL component oriented framework. Maybe he did. But who knows, company direction might have influenced him to choose otherwise.J.

    Frameworks are not a religion my friend, there is no the Real component oriented framework, just ones which might fill the tasks you want to achieve better than others.
    I for instance went for various reasons the JSF route, one it is a component oriented framework with a more than decent event system, second there already was a huge stack of third party components there so there was momentum behind it. Third there already was tool support there and you could go along with it really well without tools.
    And fourth being a standard also influenced my decision, but only to the smallest degree because the standard thing, the whole thing simply came closest to what I expect from a good webframework.
    But there is no real best framework, only ones which can fullfill your needs better than others.
  78. There are many reasons to pick JSF[ Go to top ]

    If you listen to the interview, you will note that he looked into Tapestry.
    Probably with less effort and time because Tapestry is not a spec. I certainly believe if had, he would have chosen the REAL component oriented framework. Maybe he did. But who knows, company direction might have influenced him to choose otherwise.J.
    Frameworks are not a religion my friend, there is no the Real component oriented framework, just ones which might fill the tasks you want to achieve better than others.I for instance went for various reasons the JSF route, one it is a component oriented framework with a more than decent event system, second there already was a huge stack of third party components there so there was momentum behind it. Third there already was tool support there and you could go along with it really well without tools.And fourth being a standard also influenced my decision, but only to the smallest degree because the standard thing, the whole thing simply came closest to what I expect from a good webframework.But there is no real best framework, only ones which can fullfill your needs better than others.

    These are really good points. There are many reasons to pick JSF. This does not mean that Tapestry, Wicket, etc. don't have their highlights.
  79. If you listen to the interview, you will note that he looked into Tapestry.
    Probably with less effort and time because Tapestry is not a spec. I certainly believe if had, he would have chosen the REAL component oriented framework. Maybe he did. But who knows, company direction might have influenced him to choose otherwise.J.

    Or perhaps because JSF has a lot of support from a lot of vendors and has a much larger user base. Pretty amazing considering Tapestry predates Struts.

    I like Tapestry. I'd rather work with Tapestry than a pure action based framework (Struts classic).
  80. So who cares?[ Go to top ]

    Who cares if Gavin seems to dig JSF? He blindly chose JSF because it's a spec (a standard). I wonder if he really genuinely looked deeper into one of the proven and powerful web frameworks of our time such as Wicket, Tapestry or Echo2.What most people care about is a framework that makes them productive and has a nice concept behind it. Unfortunately, there are also many whose decision are very much standards driven. I suspect Gavin's choice is the later. And that is rather unfortunate.J.

    I've said this before, JSF is extremely plugable with proper Model/View separation. I believe this was the major reason why JSF was so ideal for dropping in a whole different series of model constructs. There's no doubt in my mind that you couldn't adapt Seam to work with other frameworks-- it just wouldn't be as seamless to the developer ;-)
  81. Seamless Seam?[ Go to top ]

    There's no doubt in my mind that you couldn't adapt Seam to work with other frameworks-- it just wouldn't be as seamless to the developer ;-)

    So the Seam/JSF combination provides a more seamless approach. This begs the question: Why was the name of this framework chosen to be "Seam"?

    Seam has negative connotations, don't you think? A seam is usually something you want to hide. A visible seam is a sign of poor craftsmanship. Visible panty seams are a fashion "Don't" (according to my sister's Glamour magazines).
  82. Seam seems like a good name[ Go to top ]

    There's no doubt in my mind that you couldn't adapt Seam to work with other frameworks-- it just wouldn't be as seamless to the developer ;-)
    So the Seam/JSF combination provides a more seamless approach. This begs the question: Why was the name of this framework chosen to be "Seam"?Seam has negative connotations, don't you think? A seam is usually something you want to hide. A visible seam is a sign of poor craftsmanship. Visible panty seams are a fashion "Don't" (according to my sister's Glamour magazines).
    A line of junction formed by sewing together two pieces of material along their margins.
    A similar line, ridge, or groove made by fitting, joining, or lapping together two sections along their edges. --Dictionary.com


    It seems Seam sews the model to the view.
  83. Seam seems like a good name[ Go to top ]

    It seems Seam sews the model to the view.

    Finally! A substantive technical comment! :-) There is definitely a degree to which this is true, but it is also a bit simplistic as well. Let's consider a couple of viewpoints that actually exist in the real world.

    From the viewpoint of an object oriented purist, the separation of layers is definitely a concern. However, Seam seems :-) to actually *encourage* s separation of layers, by advocating the idea of using a stateful session bean as an adapter. Doing this naturally leads you towards *not* putting business logic into your view tier, and that seems like a good thing. The fact that you can layer your APIs completely, while still being able to bind view tier components to layer objects, is also cool.

    From the viewpoint of a developer simply trying to get his or her job done (and not caring if it conforms to purist object oriented principles :-), the fact that you can bind components directly to model tier values (without having to modify your model tier classes, or make them dependent on view tier APIs) is a huge win that Seam inherits automatically by virtue of utilizing JSF value binding expressions. No need to create value object classes, or any other sort of intermediate layering -- although, if you have such a thing, JSF and Seam are perfectly happy at dealing with those kinds of objects as well.

    Parenthetically, anyone who thinks that Java APIs should serve only the former audience and not the latter is being a bit arrogant, IMHO :-).

    Craig McClanahan
  84. Seam seems like a good name[ Go to top ]

    It seems Seam sews the model to the view.
    Finally! A substantive technical comment! :-) There is definitely a degree to which this is true, but it is also a bit simplistic as well. Let's consider a couple of viewpoints that actually exist in the real world.From the viewpoint of an object oriented purist, the separation of layers is definitely a concern. However, Seam seems :-) to actually *encourage* s separation of layers, by advocating the idea of using a stateful session bean as an adapter. Doing this naturally leads you towards *not* putting business logic into your view tier, and that seems like a good thing. The fact that you can layer your APIs completely, while still being able to bind view tier components to layer objects, is also cool.From the viewpoint of a developer simply trying to get his or her job done (and not caring if it conforms to purist object oriented principles :-), the fact that you can bind components directly to model tier values (without having to modify your model tier classes, or make them dependent on view tier APIs) is a huge win that Seam inherits automatically by virtue of utilizing JSF value binding expressions. No need to create value object classes, or any other sort of intermediate layering -- although, if you have such a thing, JSF and Seam are perfectly happy at dealing with those kinds of objects as well.Parenthetically, anyone who thinks that Java APIs should serve only the former audience and not the latter is being a bit arrogant, IMHO :-).Craig McClanahan

    Hey now.... It was not a white paper. It was just a post. Besides you left off my dictionary definition of Seam. I was going for simplicity. (At least that is the story I am sticking with).
  85. Seam seems like a good name[ Go to top ]

    A line of junction formed by sewing together two pieces of material along their margins. A similar line, ridge, or groove made by fitting, joining, or lapping together two sections along their edges. --Dictionary.com
    It seems Seam sews the model to the view.

    Gavin, could you clear this up and add a "Why is it called Seam" to your FAQ page? Thanks.

    Obviously it should have been called "Caulk". When will people learn to ask me before they announce new product names!
  86. Seam seems like a good name[ Go to top ]

    It seems Seam sews the model to the view.
    Say that 5 times fast.
  87. So who cares?[ Go to top ]

    Sorry to make it "dump on Jan" day but all your replies on this topic seem a bit, um, immature.

    Its fine if you don't like JSF. It's fine if you think Gavin made a mistake with liking it. But phrases like "He blindly chose JSF because it's a spec", "proven and powerful web frameworks of our time", and "Unfortunately, there are also many whose decision are very much standards driven" make you sound a bit like a goofball.

    Maybe try to focus on what "you" think instead of putting words into other people's mouths:

    "Gavin would tell you JBoss is the most revolutionary and best app server on the planet"

    "From your narrow mindedness I can say for sure you'll take his word for it"

    These feel more like libelous statements than reasonable arguments.

    I'm interested in "your" opinion not what you think other's would be:
    - What don't you like about developing to J2EE specs?
    - Why aren't they a good starting point for a framework?
    - Why do you feel that JSF is a mistake?

    Just don't spread so much B.S. in with it.
  88. Gavin seems to really dig JSF[ Go to top ]

    And Gavin is absolutely right. JSF is a very good framework, very extensible, and it feels like being a well-thought out spec.

    The only big minus of JSF is that it ties into JSP, and JSP wasn't built for what JSF needs from it - better with JSF 1.2, and even better with Component-Bindings (write your web-app in Java) Facelets or Clay, or whatever view-definition technology you can think of.

    A very common misconception is that JSF was built into the green - that's just not true: JSF started with concepts from UIX (an Oracle internal framework) and Struts, and both were much used frameworks at this time, one commercially and one in the open source world.

    Speaking as a team member of MyFaces - take it for granted: JSF felt right, and this is why the founders of MyFaces implemented this Spec. And the MyFaces founders _did_ evaluate just taking an existing framework at this time - or creating a new framework just like everyone else ;).

    regards,

    Martin
  89. Gavin seems to really dig JSF[ Go to top ]

    And the MyFaces founders _did_ evaluate just taking an existing framework at this time - or creating a new framework just like everyone else ;).regards,Martin

    And as a member of a competing framework I can say I did evaluate JSF and MyFaces and asked around on the MyFaces mailing list to find people that were interested in creating a non-JSP implementation (I think I proposed Velocity, which seems stupid in hind sight anyway). That time one of the developers of MyFaces (was that you?) replyed that he didn't see the problem with JSP at all, and in general there seemed to be not a lot of interest in developing such an alternative. Then I took a day to delve into the specs a bit deeper to see if it was feasible to do it on my own, but I hated the specs. I mean, if you are going to invest free time in an open source project, you might as well choose something you like, no?
  90. JSF started with concepts from UIX (an Oracle internal framework) and Struts
    Actually, that's what worries me about this standard: Struts was the first, but it's completly outdated now.
  91. Gavin seems to really dig JSF[ Go to top ]

    JSF started with concepts from UIX (an Oracle internal framework) and Struts
    Actually, that's what worries me about this standard: Struts was the first, but it's completly outdated now.

    I would not be too worried, JSF has some concepts of Struts but it is by far no advancement of Struts. It is more like a clean cut, keeping some of the good parts and getting rid of the bad ones.

    JSF is more like a Swing or Qt for webapps than Struts.
    People only knowing struts and not having programmed a normal component and event based user interface will have a hard time to shift towards JSF, because some of the stuff looks familiar (central config files, page flow definitions) but are not, because they use different syntax and different concepts.
  92. Gavin seems to really dig JSF[ Go to top ]

    JSF is more like a Swing or Qt for webapps than Struts.People only knowing struts and not having programmed a normal component and event based user interface will have a hard time to shift towards JSF,

    Is it fair to say JSF is more like ASP.NET than Struts?

    A major telco in Australia is re-writing its ASP.NET based online application in Java.

    Using JSF? No.

    The plain old Struts!
  93. Gavin seems to really dig JSF[ Go to top ]

    JSF is more like a Swing or Qt for webapps than Struts.People only knowing struts and not having programmed a normal component and event based user interface will have a hard time to shift towards JSF,
    Is it fair to say JSF is more like ASP.NET than Struts?A major telco in Australia is re-writing its ASP.NET based online application in Java.Using JSF? No.The plain old Struts!

    So? Struts is a very well established technology. JSF has not been around for that long. How is this evidence for or against JSF being like or unlike Swing or QT?
  94. Gavin seems to really dig JSF[ Go to top ]

    JSF is more like a Swing or Qt for webapps than Struts.People only knowing struts and not having programmed a normal component and event based user interface will have a hard time to shift towards JSF,
    Is it fair to say JSF is more like ASP.NET than Struts?A major telco in Australia is re-writing its ASP.NET based online application in Java.Using JSF? No.The plain old Struts!
    So? Struts is a very well established technology. JSF has not been around for that long. How is this evidence for or against JSF being like or unlike Swing or QT?

    Even if I like JSF, this is a political and technical decision, they had reasons to switch from ASP.net (probably one huge issue was the client side state saving, the other one maybe the lockin into windows). Whatever reasons there were, they probably went the save route now, and that one is Struts, which has been there for half a decade now.
    I can understand their decision. Having to switch from something new to something old often means that they must have burned their hands on something.
    <br><br>
    But to the original question, I am not too familiar with ASP.net, but given the fact that both follow similar goals JSF probably is closer to ASP.net than to Struts.
    (with some advantages it already has over ASP.net, like opensource implementations, probably more components on the freeware opensource side, more choice in development tools, easier handling without tools, and server side state saving without a back button problem, to avoid streaming of hundreds of kilobytes state saving data over the net)
  95. Gavin seems to really dig JSF[ Go to top ]

    But to the original question, I am not too familiar with ASP.net, but given the fact that both follow similar goals JSF probably is closer to ASP.net than to Struts.
    Having used all three, I can say that it is (though they are definitely not exactly alike). ASP.Net is great (from a coding standpoint), as long as you stay in the happy path. Sadly, I seldom get to stay in the happy path.
  96. Gavin seems to really dig JSF[ Go to top ]

    Is it fair to say JSF is more like ASP.NET than Struts?A major telco in Australia is re-writing its ASP.NET based online application in Java.Using JSF? No.The plain old Struts!
    So? Struts is a very well established technology. JSF has not been around for that long. How is this evidence for or against JSF being like or unlike Swing or QT?
    Even if I like JSF, this is a political and technical decision, they had reasons to switch from ASP.net (probably one huge issue was the client side state saving, the other one maybe the lockin into windows).
    You don't have to use __VIEWSTATE in ASP.NET. A friend of mine works in a company that runs a car parts warehouse and has a lot of b2b and b2c transactions. They do not use __VIEWSTATE, instead they store everything in database. Yes, they access database on every request. But database clustering existed long before J2EE clustering, so most wrinkles have been straighten out. Another benefit is that they do not have session replication issues and do not need session replication software. Their application is stateful, make no mistake about that. They simply store the state in the database instead of using session or __VIEWSTATE field.
    I am not too familiar with ASP.net, but given the fact that both follow similar goals JSF probably is closer to ASP.net than to Struts.(with some advantages it already has over ASP.net, like opensource implementations, probably more components on the freeware opensource side, more choice in development tools, easier handling without tools, and server side state saving without a back button problem, to avoid streaming of hundreds of kilobytes state saving data over the net)
    * There is one implementation of ASP.NET, and this fact makes the life of Windows devs much easier.
    * A lot of components, free, shareware and commercial. Component business for ASP.NET is far more established than for any of the Java frameworks. JSF seems to pick up in this area.
    * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)
    * Stateless applications are possible by switching view state completely off. Handling view state on the server is not a problem too. Instead of default view state implementation one can use Page::SavePageStateToPersistenceMedium, Page::SavePageStateToPersistenceMedium methods and LosFormatter class to store view state in any stream including disk file or database.
  97. * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)

    How about Java Sun Studio Creator, JDevelopper wich aren't based on Eclipse? There are also a lot of choice on Eclipse platform MyEclipse, BEA Workshop (former NitroX), WebSphere Studio, ... It is different in my opinion then the Microsoft model.
  98. * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)
    How about Java Sun Studio Creator, JDevelopper wich aren't based on Eclipse? There are also a lot of choice on Eclipse platform MyEclipse, BEA Workshop (former NitroX), WebSphere Studio, ... It is different in my opinion then the Microsoft model.

    Then of course, unlike ASP.net, you don't need tools. I am quite productive w/o tools.

    Also, unlike ASP.net, JSF is extremely extensible and open.

    I've created my own PhaseListener and navigation handler that handles CRUD navigation w/o writing XML navigation.

    Seam extends JSF. (model managment and navigation)
    Spring has extentions for JSF. (model management)
    Shale has extentions for JSF. (model management, navigation and view handling).
    Facelets (view handling)

    Is that possible with ASP.Net?

    JSF is really, really extensible.


    JSF has tool support, extensibility, developer productivety, performance, and it is the standard.
  99. tools.... JSF extensibility.[ Go to top ]

    * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)
    How about Java Sun Studio Creator, JDevelopper wich aren't based on Eclipse? There are also a lot of choice on Eclipse platform MyEclipse, BEA Workshop (former NitroX), WebSphere Studio, ... It is different in my opinion then the Microsoft model.
    Then of course, unlike ASP.net, you don't need tools. I am quite productive w/o tools.Also, unlike ASP.net, JSF is extremely extensible and open.I've created my own PhaseListener and navigation handler that handles CRUD navigation w/o writing XML navigation.Seam extends JSF. (model managment and navigation)Spring has extentions for JSF. (model management)Shale has extentions for JSF. (model management, navigation and view handling).Facelets (view handling)Is that possible with ASP.Net?JSF is really, really extensible.JSF has tool support, extensibility, developer productivety, performance, and it is the standard.

    When I say tools, I mean GUI builder tools.
  100. * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)
    How about Java Sun Studio Creator, JDevelopper wich aren't based on Eclipse? There are also a lot of choice on Eclipse platform MyEclipse, BEA Workshop (former NitroX), WebSphere Studio, ... It is different in my opinion then the Microsoft model.
    Then of course, unlike ASP.net, you don't need tools. I am quite productive w/o tools.
    One can edit HTML and develop Windows resource files with Notepad. It is just easier with tools, they come together with libraries and compiler.
    Also, unlike ASP.net, JSF is extremely extensible and open.

    I've created my own PhaseListener and navigation handler that handles CRUD navigation w/o writing XML navigation.

    Seam extends JSF. (model managment and navigation)
    Spring has extentions for JSF. (model management)
    Shale has extentions for JSF. (model management, navigation and view handling).
    Facelets (view handling)
    Some would say that these extensions stress out that JSF is a view framework (oh, I am sorry, I meant specification), quite limited in features and usability.
    Is that possible with ASP.Net?
    Are you kidding? Unless Microsoft require to sign third-party libraries with Microsoft's certificate (and to pay for it), everyone can create extensions for any Windows services. ASP.NET is a part of larger platform, that includes model management, database access and more.
    JSF is really, really extensible.
    Or just feature-limited, but thankfully with enough hooks to make it proper?
    JSF is really, really extensible.JSF has tool support, extensibility, developer productivety, performance, and it is the standard.
    The last word is the key. The status of standard will kill other frameworks and JSF will finally become ASP.NET for Java. Which brings us back to eternal question of evil software companies: Sun is not better (or worse) than Microsoft. One framework will unite developers against other platforms and will strengthen Sun's position.
  101. * There is one development tool, but there are add-ons too (how is this different from Eclipse besides the price?)
    How about Java Sun Studio Creator, JDevelopper wich aren't based on Eclipse? There are also a lot of choice on Eclipse platform MyEclipse, BEA Workshop (former NitroX), WebSphere Studio, ... It is different in my opinion then the Microsoft model.
    Then of course, unlike ASP.net, you don't need tools. I am quite productive w/o tools.
    One can edit HTML and develop Windows resource files with Notepad. It is just easier with tools, they come together with libraries and compiler.
    Also, unlike ASP.net, JSF is extremely extensible and open.I've created my own PhaseListener and navigation handler that handles CRUD navigation w/o writing XML navigation.Seam extends JSF. (model managment and navigation)Spring has extentions for JSF. (model management)Shale has extentions for JSF. (model management, navigation and view handling).Facelets (view handling)
    Some would say that these extensions stress out that JSF is a view framework (oh, I am sorry, I meant specification), quite limited in features and usability.
    Is that possible with ASP.Net?
    Are you kidding? Unless Microsoft require to sign third-party libraries with Microsoft's certificate (and to pay for it), everyone can create extensions for any Windows services. ASP.NET is a part of larger platform, that includes model management, database access and more.
    JSF is really, really extensible.
    Or just feature-limited, but thankfully with enough hooks to make it proper?
    JSF is really, really extensible.JSF has tool support, extensibility, developer productivety, performance, and it is the standard.
    The last word is the key. The status of standard will kill other frameworks and JSF will finally become ASP.NET for Java. Which brings us back to eternal question of evil software companies: Sun is not better (or worse) than Microsoft. One framework will unite developers against other platforms and will strengthen Sun's position.

    I could argue but I won't. I have no plans to use ASP.net (any time soon). I have used it in the past.

    To me the issue is moot.
  102. One can edit HTML and develop Windows resource files with Notepad. It is just easier with tools, they come together with libraries and compiler.

    In fact, I had/ have seen cases where due to bugs or unforseen complexity the IDE (VS 2003) wasn't able to pull the visual trick anymore and forced us to use a text editor instead. Not very pretty I can tell you. Another potential minus for visual designers.
  103. tools.... JSF extensibility.[ Go to top ]

    Some would say that these extensions stress out that JSF is a view framework (oh, I am sorry, I meant specification), quite limited in features and usability.

    And some would say that the ability to have such extensions is in no way a useful measure of the feature-count or usability of a framework. And some would say that the ability to have extensions is actually a good thing? Or would a closed framework that tried to pretend it was you would ever need be a good thing?
    The last word is the key. The status of standard will kill other frameworks and JSF will finally become ASP.NET for Java. Which brings us back to eternal question of evil software companies: Sun is not better (or worse) than Microsoft. One framework will unite developers against other platforms and will strengthen Sun's position.

    Intended standards succeed or fail based on their strengths. Just labelling them as standards does not help. Did JDO or EJB kill Hibernate? Of course not.
  104. tools.... JSF extensibility.[ Go to top ]

    Intended standards succeed or fail based on their strengths. Just labelling them as standards does not help. Did JDO or EJB kill Hibernate? Of course not.

    It didn't, but it might have done so. Keeping EJB out of the door in favor of Hibernate was pretty difficult not that long ago, because of the 'standards' argument. I'm not against standards, and I'm sure a lot of people here aren not. But standards come in all qualities and unfortunately, some of them are of the typical design by comittee kind.
  105. tools.... JSF extensibility.[ Go to top ]

    But standards come in all qualities and unfortunately, some of them are of the typical design by comittee kind.

    Sorry to sound rather critical, but I see so much repeating of slogans like 'design by committee'. It might be more useful if actual points could be raised for discussion. 'Design by committee' is not of itself either a good or bad aspect of any standard. (I have seen some awful 'design by individual' products!)
  106. tools.... JSF extensibility.[ Go to top ]

    I see so much repeating of slogans like 'design by committee'. 'Design by committee' is not of itself either a good or bad aspect of any standard. (I have seen some awful 'design by individual' products!)

    It's not a slogan. The word 'typical' points to my sarcasm though. You are right when you say not all designs by committee result in bad products. W3C's xml specs being a nice example of excellent results. However, besides the 'design by individual', there is something like... let's call it 'design by community'? Which differs from the other two in that in sees a lot of user participation and a bunch of iterations before it is even considered mature. In which category would you place, e.g. Hibernate?
    It might be more useful if actual points could be raised for discussion.

    I think those points have been raised enough. In this thread and the dozens on JSF before this one. JSF is an improvement over Struts. But it has issues just like any other framework out there.
  107. tools.... JSF extensibility.[ Go to top ]

    I see so much repeating of slogans like 'design by committee'. 'Design by committee' is not of itself either a good or bad aspect of any standard. (I have seen some awful 'design by individual' products!)
    It's not a slogan. The word 'typical' points to my sarcasm though. You are right when you say not all designs by committee result in bad products. W3C's xml specs being a nice example of excellent results. However, besides the 'design by individual', there is something like... let's call it 'design by community'? Which differs from the other two in that in sees a lot of user participation and a bunch of iterations before it is even considered mature.

    I have also seen various 'design by community' projects which are awful. Quality does not always arise from a democratic attitude. Often features can be selected simply based on the number of people who might use them, rather than on innovation. Of course, there is no reason why 'design by committee' projects should not involve user participation or go through a many iterations.
    In which category would you place, e.g. Hibernate?

    I have no idea. I have not researched how it was designed. How is this in any way relevant?
    It might be more useful if actual points could be raised for discussion.
    I think those points have been raised enough. In this thread and the dozens on JSF before this one. JSF is an improvement over Struts. But it has issues just like any other framework out there.

    Sorry, but until someone actually puts forward points that they specifically want to raise, I personally consider the term 'design by committee' meaningless.
  108. tools.... JSF extensibility.[ Go to top ]

    Sorry, but until someone actually puts forward points that they specifically want to raise, I personally consider the term 'design by committee' meaningless.

    In the specific case of JSF, the product would have benefitted from NOT starting out as something that had to be THE standard in one hit. There are numerous examples of APIs/ frameworks that were adopted in JSE/ JEE after they proved themselves, and I think those APIs are generally better and see a less bumpy adoption curve. However, before we get philosophical about that stuff and start arguing about JCP etc... it doesn't matter at this time. JSF is here and I am glad to see a lot of people are at least trying to address the issues people have (opposed to just saying that they don't get it). I am not crazy about the way JSF is promoted on threads like this, but I guess that is a natural reaction to percepted FUD campaign against it.
  109. Sorry, but until someone actually puts forward points that they specifically want to raise, I personally consider the term 'design by committee' meaningless.
    In the specific case of JSF, the product would have benefitted from NOT starting out as something that had to be THE standard in one hit. There are numerous examples of APIs/ frameworks that were adopted in JSE/ JEE after they proved themselves, and I think those APIs are generally better and see a less bumpy adoption curve. However, before we get philosophical about that stuff and start arguing about JCP etc... it doesn't matter at this time. JSF is here and I am glad to see a lot of people are at least trying to address the issues people have (opposed to just saying that they don't get it). I am not crazy about the way JSF is promoted on threads like this, but I guess that is a natural reaction to percepted FUD campaign against it.

    By the way JSF wasn't written from scratch, it is an evolution of Oracle UIX and Struts, and probably managed beans came from Spring ideas.
  110. tools.... JSF extensibility.[ Go to top ]

    I guess that is a natural reaction to percepted FUD campaign against it.

    I'd agree. It is the case for me anyway. ;o)
  111. Gavin seems to really dig JSF[ Go to top ]

    Having to switch from something new to something old often means that they must have burned their hands on something.

    No hands burned there.

    Windows lockin and integration with the backend might probably be reasons to switch to Java.

    I cannot guess the rationals behind JSF vs Struts, but after several years (JSF started not too much later than Struts), JSF has not made much inroads into the corporate world. Things might change with JEE5, but probably when it is the next IT down turn or the next wave of offshoring.
  112. Gavin seems to really dig JSF[ Go to top ]

    I cannot guess the rationals behind JSF vs Struts, but after several years (JSF started not too much later than Struts), JSF has not made much inroads into the corporate world.

    Sorry, but I have to question your facts here. JSF started much later than struts. There was a thread on TSS last year in May to mark the 5th anniversary of Struts. You participated in it! However JSF was only released on 11th March 2004. That is certainly much later than struts.

    Also, if you are going to counter one of the statements about JSF use, how about some evidence? Gavin King quoted above said "We can see a lot of adoption of JSF". Simply stating that he is wrong does not help the debate - do you have any figures for corporate JSF use?
  113. Gavin seems to really dig JSF[ Go to top ]

    Sorry, but I have to question your facts here. JSF started much later than struts.

    The Struts project (then a one man project) started in 2000. The first JSR for JSF started in 2001.
  114. Gavin seems to really dig JSF[ Go to top ]

    Sorry, but I have to question your facts here. JSF started much later than struts.
    The Struts project (then a one man project) started in 2000. The first JSR for JSF started in 2001.

    So you expect mass corporate uptake of a technology as soon as the JSR started? We are talking about when a product was generally available, not when it was first worked on.
  115. Gavin seems to really dig JSF[ Go to top ]

    People only knowing struts and not having programmed a normal component and event based user interface will have a hard time to shift towards JSF, because some of the stuff looks familiar (central config files, page flow definitions) but are not, because they use different syntax and different concepts.
    Which probably explains why couldn't stand Struts from the first time I saw it. I was, from the start, looking for an Echo or JSF.
  116. No offense but...[ Go to top ]

    What does Gavin really know about writing web frameworks?

    That doesn't detract from how truly innovative and superior Hibernate is as a means of persistence, but.....
  117. No offense but...[ Go to top ]

    What does Gavin really know about writing web frameworks? That doesn't detract from how truly innovative and superior Hibernate is as a means of persistence, but.....

    Well I suggest you to take a look at Seam. To write this kind of framework, you need *some* web frameworks knowledge in my opinion.

    Please argue on what he says in the interview so we can have a constructive discussion not on his *hidden agenda* or other crap of this kind. It's not a political forum after all..
  118. No offense but...[ Go to top ]

    ... Please argue on what he says in the interview so we can have a constructive discussion not on his *hidden agenda* or other crap of this kind. It's not a political forum after all..

    Fair enough. I don't agree that styling via css alone is more than enough and the ~only~ way people should be doing web development. In order to have a flexible framework I believe it is much better to allow a little bit more control over the actual html being output and not rely on css alone. This is a personal opinion based on experiences with various libraries that have tried to do this and decided it wasn't the best idea. There are just too many situations where this creates customization problems.

    So, I would say the css statement alone sort of rubbed me the wrong way and indicated a certain level of experience. Just an opinion though....
  119. No offense but...[ Go to top ]

    ... Please argue on what he says in the interview so we can have a constructive discussion not on his *hidden agenda* or other crap of this kind. It's not a political forum after all..
    Fair enough. I don't agree that styling via css alone is more than enough and the ~only~ way people should be doing web development. In order to have a flexible framework I believe it is much better to allow a little bit more control over the actual html being output and not rely on css alone. This is a personal opinion based on experiences with various libraries that have tried to do this and decided it wasn't the best idea. There are just too many situations where this creates customization problems. So, I would say the css statement alone sort of rubbed me the wrong way and indicated a certain level of experience. Just an opinion though....

    Well he is right in a sense that a clean design should enforce CSS wherever possible, that some browsers with currently 85% marketshare prevent this to a certain degree is another issue (and lots of so called html designers as well).

    But I see that as a non issue in JSF anyway, there are enough ways for a html fallback, they are just not enforced like other frameworks do, which simply add a thin dynamisation layer on top of html.

    Anyway given the fact that Seam currently is one of a really small number for frameworks bringing totally new stuff onto the table in the web framework space is enough justification not to dismiss Gavins words as being from a person who does not know what he is talking about.

    He has proven that enough that he also knows his way around in the web framework space.

    (I would not have thought otherwise, if you do projects you usually have to deal with web centric apps a lot of times, so you get enough exposure to all kind of web frameworks, to get a good indication where to push your personal preferences to)
  120. No offense but...[ Go to top ]

    Jesse, you're right in saying that CSS isn't the only answer, but it is an answer to the degree of not needing to formulate your whole view layer around designers within the structual markup. We are a ways in on a *very* large project and our designer spends 95% of his time just setting styles/classes and modifying CSS files. Even our JS events are externally decorated instead of explicitly defining them as attributes on structual elements. It's a new route of development that does require expertise, but if you have expert designers, then this development route makes a ton of sense w/ retaining control by the appropriate parties.
  121. No offense but...[ Go to top ]

    I don't think I know enough about JSF or facelets to give a very strong opinion on anything specific to either of them. Can only respond to things I read/hear. (doesn't require as much work ;) )

    I do like the external js, as well as css.

    I still view these things as seperate from what is happening to the actual html though. You know, html is the core of it, the DOM, it holds all our data and structures certain aspects of the view. I'm used to and prefer to control this part of things, if a component/js package/whatever wants to come along and decorate my html then that is great and everyone's happy.

    Facelets are definitely a step in the right direction over what the original JSF impl seems to be going for, even if I think there are fundamental flaws in JSF that feel very limiting.

    Thankfully we have all sorts of infrastructure that supports new and innovative open source dev to prevent lock in to "one all knowing being" so it's a moot point. :)
  122. No offense but...[ Go to top ]

    Jesse, you're right in saying that CSS isn't the only answer, but it is an answer to the degree of not needing to formulate your whole view layer around designers within the structual markup. We are a ways in on a *very* large project and our designer spends 95% of his time just setting styles/classes and modifying CSS files. Even our JS events are externally decorated instead of explicitly defining them as attributes on structual elements. It's a new route of development that does require expertise, but if you have expert designers, then this development route makes a ton of sense w/ retaining control by the appropriate parties.

    Totally agree Jacob. Our designer here works the same way. He just needs to change its css and voilà everything is done.

    Another thing we like with this approach is that he can have different versions of the same css and manage them a independant project using Maven 2. He can work on his csss while the developpers work on the source code and knowing the integration won't be a problem.
  123. No offense but...[ Go to top ]

    What does Gavin really know about writing web frameworks? That doesn't detract from how truly innovative and superior Hibernate is as a means of persistence, but.....

    Seems to me that if he has the talent to do the research and design of a professional level framework in one arena that he should at least be taken seriously applying that same talent elsewhere. Did he succeed? I don't know but dismissing him as just a database programmer seems to be something an HR employee would do:

    "Yes, Gavin I see you've had some good Hibernate experience but we're looking for a Struts guy"
  124. No offense but...[ Go to top ]

    What does Gavin really know about writing web frameworks? That doesn't detract from how truly innovative and superior Hibernate is as a means of persistence, but.....

    From a series of conversations with Gavin about these topics, over a fairly long period of time, I can assure you that Gavin knows a heck of a lot more about the architectural issues around web frameworks than most people I know.

    I also get incredibly depressed when I see this kind of thread over and over again on TSS ... focusing on personalities (and, quite often, personal attacks) instead of technology, useless speculations over what someone *thinks* instead of what they *said* or *did*, a myopic belief that if person X thinks technology A is "good" then person X must also believe that technology B is "bad", and so on ... sheesh.

    Craig McClanahan
  125. you're right...[ Go to top ]

    I immediately felt bad for the way my original post came off...Sort of a talk first and think later approach.

    The original intent wasn't to attack anyone in particular, but instead to try and bring context into the web area..I'm sure Gavin's perfectly capable of diving into a framework and owning all the portions of it eventually...

    Of course it's also hard to not feel like a response is needed when all people read about is SEAM and then hear the javaposse interview..I know he doesn't think JSF isn't the only good technology out there, but it didn't seem like this was a well known public sort of thing so it gets frustrating sometimes when more zealout types start spouting off about how "obvious" it is that JSF is the best thing ever...Every framework has positive/negative points..

    Either way the original post was out of line and I humbly apologize for what it contained..
  126. you're right...[ Go to top ]

    I immediately felt bad for the way my original post came off...Sort of a talk first and think later approach. The original intent wasn't to attack anyone in particular, but instead to try and bring context into the web area..I'm sure Gavin's perfectly capable of diving into a framework and owning all the portions of it eventually...Of course it's also hard to not feel like a response is needed when all people read about is SEAM and then hear the javaposse interview..I know he doesn't think JSF isn't the only good technology out there, but it didn't seem like this was a well known public sort of thing so it gets frustrating sometimes when more zealout types start spouting off about how "obvious" it is that JSF is the best thing ever...Every framework has positive/negative points..Either way the original post was out of line and I humbly apologize for what it contained..

    Hey no problem Jesse! I think your second post made it clear you weren't trying to disrespect anyone and you weren't one of those "I HATE EVERY SPECS BECAUSE I KNOW BETTER THEN EVERYONE" people.
  127. Slashdot like isn't it[ Go to top ]

    <blockquoteI also get incredibly depressed when I see this kind of thread over and over again on TSS ... focusing on personalities (and, quite often, personal attacks) instead of technology, useless speculations over what someone *thinks* instead of what they *said* or *did*, a myopic belief that if person X thinks technology A is "good" then person X must also believe that technology B is "bad", and so on ... sheesh.
    I agree. The constant conspiracy theory stuff is annoying.

    I've never worked at Sun, Oracle, etc. I get accused of being on the JSF payroll often.
  128. No offense but...[ Go to top ]

    I also get incredibly depressed when I see this kind of thread over and over again on TSS ... focusing on personalities (and, quite often, personal attacks) instead of technology, useless speculations over what someone *thinks* instead of what they *said* or *did*, a myopic belief that if person X thinks technology A is "good" then person X must also believe that technology B is "bad", and so on ... sheesh.

    Craig McClanahan

    I completely agree. I don't understand why people insist on attacking others with gratuitous negative comments. Sadly, there will always be such people around. I always think, "if you don't like it, suggest how it could be improved."

    Also, it's enough already with the accusations of hidden agendas, political intentions, being paid to have an opinion, etc.! If you are convinced that this is what's going on, and that TSS is the vehicle for these conspiracies, then why are you still reading TSS?

    On the other hand, because this "noise" is a part of life, we should give even more value and praise to those who take the time to contribute comments that are actually constructive. This doesn't mean positive comments only -- you could say that a simple "XYZ framework rocks!" is no more constructive a comment than "XYZ framework sucks!" -- but at least an attitude that is open-minded enough for discussion of technical issues, leaving personal insults aside.

    And if someone writes a personal attack towards you, don't fall for the trap, resist retaliation, and be the bigger person! The rest of us will notice and will respect you for it.

    *whew* that's enough, feel free to make fun of me, I can take it :-)

    Frederic
  129. No offense but...[ Go to top ]

    I completely agree. I don't understand why people insist on attacking others with gratuitous negative comments. Sadly, there will always be such people around. I always think, "if you don't like it, suggest how it could be improved."

    I wish there were more people who approached public discourse with this attitude. Sadly, part of the price we pay for free speech is putting up with people who behave like little boys at the beach that, rather than building their own sand castles, get some psychological benefit from kicking down the castles that others have built.
    Also, it's enough already with the accusations of hidden agendas, political intentions, being paid to have an opinion, etc.! If you are convinced that this is what's going on, and that TSS is the vehicle for these conspiracies, then why are you still reading TSS?

    Mere happenstance ... I've reduced my reading of TSS threads (due to the decreasing signal-to-noise ratio) from several times a day to a couple times per week. If you really want to see what *I* personally think is important, pay more attention to what I *do* (Java Studio Creator, Struts, MyFaces) than what I talk about. I wish other people who post here would take the same approach.
    On the other hand, because this "noise" is a part of life, we should give even more value and praise to those who take the time to contribute comments that are actually constructive. This doesn't mean positive comments only -- you could say that a simple "XYZ framework rocks!" is no more constructive a comment than "XYZ framework sucks!" -- but at least an attitude that is open-minded enough for discussion of technical issues, leaving personal insults aside.And if someone writes a personal attack towards you, don't fall for the trap, resist retaliation, and be the bigger person! The rest of us will notice and will respect you for it.

    No question that both positive and negative comments have their place here. I just (perhaps naively :-) wish that the comments could be based on technical issues, not personalities or politics, or even suppositionns about what particular people might think. Without that, we might as well have a People Magazine clone in cyberspace :-).
    *whew* that's enough, feel free to make fun of me, I can take it :-)

    As the target of more than a few personal attacks in this forum, I can tell you that you're making the right choice :-). Ignoring the personal attacks on ourselves is absolutely the right action. Judging the total percentage of noise, versus the total percentage of signal, is a different story altogether. Personally, I'm approaching the limit where I'm leaning towards "this site is a waste of my time" even if reading TSS is just what I do during my first couple of cups of coffee during the day.

    Craig
  130. I completely agree. I don't understand why people insist on attacking others with gratuitous negative comments. Sadly, there will always be such people around. I always think, "if you don't like it, suggest how it could be improved."
    I wish there were more people who approached public discourse with this attitude. Sadly, part of the price we pay for free speech is putting up with people who behave like little boys at the beach that, rather than building their own sand castles, get some psychological benefit from kicking down the castles that others have built.
    Also, it's enough already with the accusations of hidden agendas, political intentions, being paid to have an opinion, etc.! If you are convinced that this is what's going on, and that TSS is the vehicle for these conspiracies, then why are you still reading TSS?
    Mere happenstance ... I've reduced my reading of TSS threads (due to the decreasing signal-to-noise ratio) from several times a day to a couple times per week. If you really want to see what *I* personally think is important, pay more attention to what I *do* (Java Studio Creator, Struts, MyFaces) than what I talk about. I wish other people who post here would take the same approach.
    On the other hand, because this "noise" is a part of life, we should give even more value and praise to those who take the time to contribute comments that are actually constructive. This doesn't mean positive comments only -- you could say that a simple "XYZ framework rocks!" is no more constructive a comment than "XYZ framework sucks!" -- but at least an attitude that is open-minded enough for discussion of technical issues, leaving personal insults aside.And if someone writes a personal attack towards you, don't fall for the trap, resist retaliation, and be the bigger person! The rest of us will notice and will respect you for it.
    No question that both positive and negative comments have their place here. I just (perhaps naively :-) wish that the comments could be based on technical issues, not personalities or politics, or even suppositionns about what particular people might think. Without that, we might as well have a People Magazine clone in cyberspace :-).
    *whew* that's enough, feel free to make fun of me, I can take it :-)
    As the target of more than a few personal attacks in this forum, I can tell you that you're making the right choice :-). Ignoring the personal attacks on ourselves is absolutely the right action. Judging the total percentage of noise, versus the total percentage of signal, is a different story altogether. Personally, I'm approaching the limit where I'm leaning towards "this site is a waste of my time" even if reading TSS is just what I do during my first couple of cups of coffee during the day.Craig

    Personal attacks are quite common on most online forums not to mention blogs. I've been both a victim and an occasional perpetrator. It is like driving in a car. People in a car are a lot more aggresive than people standing in a line at the market. There are things people say online that they would never dream of saying face to face.

    I was never attacked personally (to my recollection) until I first wrote a blog declaring that JSF was a good framework. Then the attacks came out of the wood work. There is a lot of passion about web frameworks.

    Here is when my trouble started:
    http://java.sys-con.com/read/46402.htm
    My guess is that the same project would have taken twice as long if I did it with Struts instead of JSF because it was a fairly rich application (custom sorting, post backs to populate list boxes, auto populate fields based on user actions, etc.). JSF is much more natural than Struts. I think WebWork, and Spring MVC are improvements on Struts Model 2 MVC, but I have been bitten by the event-driven bug. The only other framework I would consider using instead of JSF would be Tapestry. In short, I dig JSF.

    Apparently it is popular to bash Sun and J2EE. JSF does not deserve it.
    ...
    For me the killer stack is JSF + Hibernate + Spring. The verdict is still out on Tapestry (I need more experience with it). --Sept 04

    The above statement did not make a lot of Struts, Tapestry and WebWork users (not to mention contributors) happy.

    Then I wrote a series on JSF FUD and how easy it was to work with:
    http://www-128.ibm.com/developerworks/library/j-jsf1
    http://www-128.ibm.com/developerworks/library/j-jsf2
    http://www-128.ibm.com/developerworks/library/j-jsf3
    http://www-128.ibm.com/developerworks/library/j-jsf4
    Just in case you're thinking that doing it with Struts would have been easier, my estimate is that it would take at least twice the effort to create the Struts version of the simple JSF application you built here. To build the same example app in Struts you would need two action classes for the two buttons, each requiring its own set of action mappings. You would also need an action mapping to load the first page, at least assuming you were following the Model 2 recommendation. To mimic JSF's default error handling and validation you would have to configure Struts to use the validator framework or implement the equivalent in the validate method on an ActionForm. You would also have to either declare a DynaValidatorForm in the Struts config or create an ActionForm and override the validate method or use the subclass of the ValidatorForm with the hooks into validator framework. And finally, you would probably need to configure some forwards (possibly two sets for each action) or global forwards to be used by all the actions.

    In addition to doubling your coding, Struts takes a lot more effort for new developers to learn. I know this because I've written both a Struts course and a JSF course and I've taught them both. Developers pick up JSF easily and struggle with Struts. I believe a lot more forethought went into the design of JSF than Struts. JSF just makes more logical sense; it is intuitive. Struts was collected and evolved. JSF was specified and created. JSF development is simply more productive than Struts development in my book. --Feb 05 IBM DeveloperWorks

    It really nice to see this forum where there is overwhelming support for JSF and many folks willing to come out and say "I use it and I like it". This was not always the case.

    JSF has awesome tool support.
    You can work with JSF without tools.
    JSF has awesome third party component libraries.

    There is no other Java web framework that even comes close.

    The Java answer to RoR will be something JSF based and it will be awesome (Perhaps Seam + JSF + Gavin's new CRUD framework or maybe something else).

    If you combine JSF with Facelets, it will be even better.

    I don't think the answer to negative publicity is to ignore it.
  131. I was never attacked personally (to my recollection) until I first wrote a blog declaring that JSF was a good framework. Then the attacks came out of the wood work.

    Don't you mean, the attacks came out of the webwork?

    Sorry, after my bad wicket/wicked joke about your sense of humour, I couldn't resist..:-)
  132. No offense but...[ Go to top ]

    And if someone writes a personal attack towards you, don't fall for the trap, resist retaliation, and be the bigger person! The rest of us will notice and will respect you for it.
    Or, poke the rabid dog while he is not looking and then run (make sure there is a tree close by)! :)
  133. cite="http://www.javaposse.com/index.php?post_id=59304"> then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.

    That's rich considering JSF in all the Sun and MyFaces components embed static HTML and Javascript in Java classes, a la Servlets, 1999.
  134. cite="http://www.javaposse.com/index.php?post_id=59304"> then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.
    That's rich considering JSF in all the Sun and MyFaces components embed static HTML and Javascript in Java classes, a la Servlets, 1999.

    Only the renderers do, one way or the other you have to produce some markup.
    However, I could think of using a different templating technology for rendering as well, nothing except a huge speed hit would prevent you to to use velocity for instance
    as template, all the component renderer would have to do
    is to fill the velocity context push the component data in and let velocity render the markup.
    But that would result in a velocity call per component displayed. In the end it would be probably better to go entirely with a Velocity based rendering frontend, which also means huge work, because you have to add renderers.

    I think in the long run something like a component lib based on facelets should be the way to go.
    (I am overall happy with jsf but the component API is definitely one thing I have constant gripes with, speaking as a component developer, and app developer)
  135. cite="http://www.javaposse.com/index.php?post_id=59304"> then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.
    That's rich considering JSF in all the Sun and MyFaces components embed static HTML and Javascript in Java classes, a la Servlets, 1999.

    Scott,

    I agree with you. This is one of the things I hate the most about writing JSF components. I've used Velocity within the component to work around this problem. It worked well. And, I've come to really like Velocity.

    In the future, I plan on using the Facelets API to access the Facelets templating internal to a JSF component.

    Also, you can now write aggregation components ala Facelets, which are similar but different. ;o)

    Although this problem has not been addressed by the JSF specification, there are many solutions to it.

    At times solutions come out before the spec. addresses them.
  136. So wide of the mark[ Go to top ]

    "A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS."
    The above comment is just so wide of the mark. The CSS thing is just a red herring. Of course anyone working with a HTML presentation layer should make extensive use of CSS. That goes without saying. But the HTML template is still unambiguously part of the presentation layer (as is the CSS). It's just lighter and more maintainable presentation template. The real issue that was being raised is where should the component definition go? Even "after considering this a lot", he seems unaware of the fact that Tapestry gives you the choice. You can embed the component definition in the HTML template (an "implicit component" in Tapestry terms) or you can put it in a separate component specification (an "explicit component"). And this has been the case since the version of Tapestry prior to the current one. So that the primary reason given for not going with Tapestry is based on a faulty (or very out-of-date) understanding of the framework.
  137. So wide of the mark[ Go to top ]

    "A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS."
    The above comment is just so wide of the mark. The CSS thing is just a red herring. Of course anyone working with a HTML presentation layer should make extensive use of CSS. That goes without saying. But the HTML template is still unambiguously part of the presentation layer (as is the CSS). It's just lighter and more maintainable presentation template. The real issue that was being raised is where should the component definition go? Even "after considering this a lot", he seems unaware of the fact that Tapestry gives you the choice. You can embed the component definition in the HTML template (an "implicit component" in Tapestry terms) or you can put it in a separate component specification (an "explicit component"). And this has been the case since the version of Tapestry prior to the current one. So that the primary reason given for not going with Tapestry is based on a faulty (or very out-of-date) understanding of the framework.

    This is out of date in both directions. With Facelets you can do HTML based component tempaltes.

    At times is makes sense to go up the abstraction latter and drop more than a simple element on a page.

    <calendar/>

    <tree/>

    <tabpanel/>

    Both Tapestry and JSF/Facelets let you move up and down the abstraction ladder.
  138. So wide of the mark[ Go to top ]

    This is out of date in both directions. With Facelets you can do HTML based component tempaltes. ... Both Tapestry and JSF/Facelets let you move up and down the abstraction ladder.
    Sorry Rick, but this is precisely the point I was making, namely that you can do embedded or externalised component definitions in either. Indeed it's obvious that you can have HTML-embedded component definitions in the JSF world because that's precisely what Gavin expressed a preference for in the original transcript. My point related to the fact that he felt that this preference was "nicer" than "Tapestry's idea of plain HTML and seperating out the component definitions". I was merely pointing out this is several years out of date, as Tapestry also allows you to do both.

    The other, separate, issue is the role of CSS. A component just renders itself as markup. You are perfectly free to have your components render as CSS-aware markup (with appropriate id and class attributes) or as old-school noisy HTML. Obviously the former is preferable but it is an entirely orthogonal issue to whether the component specifications should be embedded or externalised. It's spurious to invoke CSS in this context.
  139. Sun Java Creator for JSF[ Go to top ]

    I would like to congratulate Sun for providing us Sun Java Creator 2.0. It is a very nice tool for working with JSF. If you haven't tried it, just do it. It makes the work with JSF very smooth and easy as pie. Not yet as good as Delphi but it will make its way, IMO. With Object, Data Binding included you can make a Web application in very easy way.

    I think if Netbeans 5/6 will support JSF (based on Java Creator) and also Swing (Matisse) in the same IDE, also those UML and BPEL (Netbeans 5.5 Preview), everyone will think twice to use Eclipse or any other IDE ;-)

    Good work Sun!

    Cheers,
    Lofi.

    Hybrid Enterprise Java Open Source Application Development?
    Business Layer : EJB, DODS, Hibernate, Spring
    Presentation Layer : XMLC/EAF, JSF, Swing
    Specification Layer : POJI/POJO
    -> http://ejosa.sourceforge.net
  140. HttpSession vs SFSB[ Go to top ]

    Can anyone elaborate on Gavin's argument that SFSB is just as good as HttpSession, if not better? If I run into scalability problems from shoving too much in the session, won't I run into the same problems, at about the same time (i.e. about the same number of concurrent users), if I'm shoving it into SFSBs instead? What's the solution? Enlarge the cluster of JBoss app servers? Vs keep it in the session and buy a Coherence license?
  141. HttpSession vs SFSB[ Go to top ]

    Can anyone elaborate on Gavin's argument that SFSB is just as good as HttpSession, if not better? If I run into scalability problems from shoving too much in the session, won't I run into the same problems, at about the same time (i.e. about the same number of concurrent users), if I'm shoving it into SFSBs instead? What's the solution? Enlarge the cluster of JBoss app servers? Vs keep it in the session and buy a Coherence license?

    If you put stuff in your session AND you use session replication AND you don't use a smart HttpSession implementation (like Coherence provides) AND/ OR you decide not to abstract from the HttpSession in the first place THEN he is probably right. It's always good to work with abstractions so that you may decide to optimize according to your situation (like using a database instead). SFSB is one of the options you have for abstracting.
  142. Sun Java Creator for JSF[ Go to top ]

    I would like to congratulate Sun for providing us Sun Java Creator 2.0. It is a very nice tool for working with JSF. If you haven't tried it, just do it. It makes the work with JSF very smooth and easy as pie. Not yet as good as Delphi but it will make its way, IMO. With Object, Data Binding included you can make a Web application in very easy way.I think if Netbeans 5/6 will support JSF (based on Java Creator) and also Swing (Matisse) in the same IDE, also those UML and BPEL (Netbeans 5.5 Preview), everyone will think twice to use Eclipse or any other IDE ;-)Good work Sun!Cheers,Lofi.Hybrid Enterprise Java Open Source Application Development?Business Layer : EJB, DODS, Hibernate, SpringPresentation Layer : XMLC/EAF, JSF, SwingSpecification Layer : POJI/POJO-> http://ejosa.sourceforge.net

    The problem with constant drag & drop is that it never stops. Using something like Facelets allows me to abstract things and reuse them instead of generate them, generate them, generate them. I hate WYSIWYG tools. They are good for prototyping and that is it. I want code completion and the tool to get out of my way as much as possible. Text files rock!
  143. tapestry[ Go to top ]

    It is good to hear that Gavin considered tapestry. I've been using struts forever, and am trying to select my teams next front end technology for java applications.
    I remember back in the 90's when sun announced the J2ee roles- deployer, page designer, developer, etc, and would like to someday see us able to leverage html experts in our application dev process, but at this point (at least w/ the jsp renderer), this seems impossible in JSF, or at least not an improvement on struts. I would like WYSIWIG editors to work w/ my templates, and not require expensive java specific tooling to build the "web piece" of the applications.

    JSP tags, and JSF tags still seem to have too much of the "model" details in them, so will continue to be out of reach of my html prototyping teammates.

    One more thing. Tapestry allows my to unit test my Pages w/out needing a servlet engine. Will JSF give me that?
    (not sure yet)

    Thanks Gavin for allowing my Domain model programming to prosper w/ Hibernate!
  144. tapestry[ Go to top ]

    Tapestry allows my to unit test my Pages w/out needing a servlet engine. Will JSF give me that?(not sure yet)Thanks Gavin for allowing my Domain model programming to prosper w/ Hibernate!

    It has been doable since the first version. You never see and touch any HttpXXX objects.
  145. tapestry[ Go to top ]

    It is good to hear that Gavin considered tapestry. I've been using struts forever, and am trying to select my teams next front end technology for java applications.I remember back in the 90's when sun announced the J2ee roles- deployer, page designer, developer, etc, and would like to someday see us able to leverage html experts in our application dev process, but at this point (at least w/ the jsp renderer), this seems impossible in JSF, or at least not an improvement on struts. I would like WYSIWIG editors to work w/ my templates, and not require expensive java specific tooling to build the "web piece" of the applications. JSP tags, and JSF tags still seem to have too much of the "model" details in them, so will continue to be out of reach of my html prototyping teammates. One more thing. Tapestry allows my to unit test my Pages w/out needing a servlet engine. Will JSF give me that?(not sure yet)Thanks Gavin for allowing my Domain model programming to prosper w/ Hibernate!

    Facelets allows the same style of development with JSF.
  146. Gavin seems to really dig JSF[ Go to top ]

    Just got back from vacation :-)

    I'd like to make clear, that in defending JSF, I am not in ANY way trying to detract from other web frameworks that are out there, or say that we will never support anything other than JSF in Seam. Each have their strengths and weaknesses, JSF as much as any other.

    What I do believe is that JSF has been subject to a totally unnecessary level of negativity. It's a really nice approach, with some excellent features that other frameworks don't have (which of course does not deny that other frameworks also have their own unique and excellent features), and with a combination of features that most matched the philosophy of Seam.
  147. Gavin seems to really dig JSF[ Go to top ]

    Just got back from vacation :-)I'd like to make clear, that in defending JSF, I am not in ANY way trying to detract from other web frameworks that are out there, or say that we will never support anything other than JSF in Seam. Each have their strengths and weaknesses, JSF as much as any other.What I do believe is that JSF has been subject to a totally unnecessary level of negativity. It's a really nice approach, with some excellent features that other frameworks don't have (which of course does not deny that other frameworks also have their own unique and excellent features), and with a combination of features that most matched the philosophy of Seam.

    I don't think JSF is perfect either, but it does not deserve the negative press it recieved. I agree with your statements.
  148. Gavin seems to really dig JSF[ Go to top ]

    I wonder if these pedantic debates about frameworks/patterns exist in the .NET world. IMHO, it's not the framework, its the tools that make you productive.

    With Sun's Free Java studio, JSF has got me interested. Drag and drop CRUD web-apps are a possibility now.

    Its a win/win for me, if I have a free tool that hides the complexity of a framework from me, yet gives me the hooks necessary to dig into the dirt if I have to.

    I don't see that fancy tool support with non-JSF frameworks. Maybe I'm missing something..?
  149. Gavin seems to really dig JSF[ Go to top ]

    I wonder if these pedantic debates about frameworks/patterns exist in the .NET world. IMHO, it's not the framework, its the tools that make you productive.With Sun's Free Java studio, JSF has got me interested. Drag and drop CRUD web-apps are a possibility now.Its a win/win for me, if I have a free tool that hides the complexity of a framework from me, yet gives me the hooks necessary to dig into the dirt if I have to.I don't see that fancy tool support with non-JSF frameworks. Maybe I'm missing something..?

    I agree to a degree. Unlike .Net, with JSF you can use fancy IDE tools, but you don't have too. I don't think that is the case with .Net. I think you are more tied to the tools. What I like about Seam is that is seems to reduce the amount of configuration (managed beans and such) so it is even more friendly to developers who don't like WYSIWYG tools.
  150. JSF?[ Go to top ]

    Haven't heard JSF used in any major projects in Sydney (AU). Could someone tell me one (such project)?

    Seems JSF a complex game for a few "elite", just as EJB2 entity bean.
  151. JSF?[ Go to top ]

    JSF is not as difficult as EJB2. After discovering it's secrets. It will make your life easier. there are many books out there. You can start from myfaces project and build your own application. Good luck.
  152. JSF?[ Go to top ]

    JSF is not as difficult as EJB2. After discovering it's secrets. It will make your life easier. there are many books out there. You can start from myfaces project and build your own application. Good luck.

    EJB2 EB was not diffuclut in a small application either, and actually made your life easier (than JDBC API) if you have tool support to create the EBs. It only got complicated in a large application.
  153. Who cares?[ Go to top ]

    A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.

    You can define components in the page with Tapestry.

    I don't think that Gavin is saying that JSF is better or that he has a hidden agenda. I just think he's just saying that he started using JSF and thought it was good. Nothing like low expectations... ;)

    If someone is truely evaluating JSF vs. Tapestry, they should look at something like: http://www.theserverside.com/articles/article.tss?l=JSFTapestry
  154. Who cares?[ Go to top ]

    A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.
    You can define components in the page with Tapestry. I don't think that Gavin is saying that JSF is better or that he has a hidden agenda. I just think he's just saying that he started using JSF and thought it was good. Nothing like low expectations... ;)If someone is truely evaluating JSF vs. Tapestry, they should look at something like: http://www.theserverside.com/articles/article.tss?l=JSFTapestry

    So we are back to guessing what Gavin thinks... I thought we agreed not to channel Gavin. :o)

    Since we are channleling Gavin, I bet he thinks I don't want every whack job webframework fanatic breathing down my neck so I won't tell everyone I picked JSF becuase is: really darn good, the standard, has tons of components, and tons of tool support. It is frankly heads and shoulders above the rest both in technology and industry adoption. Hell its not perfect, but it is getting better and better.

    BTW Read the Seam documents, Gavin loves Facelets too.
  155. Who cares?[ Go to top ]

    A lot of people have the idea (that Tapestry's) idea of plain HTML and seperating out the component definitions (is a good idea). Frankly, after considering this a lot, I actually I find it nicer to put the component definitions in the page. The argument that but then you are mixing your semantic data definintion with your presentation does not hold water because it is 2006 guys and you are not suppose to be doing presentation in your HTML. You are suppose to be doing it in your CSS.
    You can define components in the page with Tapestry. I don't think that Gavin is saying that JSF is better or that he has a hidden agenda. I just think he's just saying that he started using JSF and thought it was good. Nothing like low expectations... ;)If someone is truely evaluating JSF vs. Tapestry, they should look at something like: http://www.theserverside.com/articles/article.tss?l=JSFTapestry
    So we are back to guessing what Gavin thinks... I thought we agreed not to channel Gavin. :o)Since we are channleling Gavin, I bet he thinks I don't want every whack job webframework fanatic breathing down my neck so I won't tell everyone I picked JSF becuase is: really darn good, the standard, has tons of components, and tons of tool support. It is frankly heads and shoulders above the rest both in technology and industry adoption. Hell its not perfect, but it is getting better and better.BTW Read the Seam documents, Gavin loves Facelets too.

    BTW I don't dispute that Tapestry is a really good framework.
  156. Goodbye for now[ Go to top ]

    It seems this thread is winding down. Thanks for all of the comments. I wanted to bring attention to Gavin's thoughts on JSF as many (myself included) view Gavin as one of the most influential Java developers in the industry. My goal is not to post another thing about JSF for a month (two posts within a week or so is too much).

    Thanks again.

    --Yours Truly
    Evil JSF Enthusiast
    Rick Hightower
  157. Reading Gavin's interview I wrote about my own experience with JSF:
    http://talkinghub.com/message/350.html#message
    General idea: Java web development can be much easier!

    Denis Krukovsky
    http://talkinghub.com/
  158. what component model?[ Go to top ]

    i just read through Rick Hightower's JSF tutorial at http://www-128.ibm.com/developerworks/library/j-jsf1/

    There's a controller, a model object, an xml config file, and a jsp page. Um, what's so different about this from a request/action based framework?
  159. what component model?[ Go to top ]

    i just read through Rick Hightower's JSF tutorial at http://www-128.ibm.com/developerworks/library/j-jsf1/ There's a controller, a model object, an xml config file, and a jsp page. Um, what's so different about this from a request/action based framework?

    It adds a very component centric approach to the mix, you have components, you have events (not only an action), the whole UI rendering layer is split onto mvc renderers on component level. On the backend side you can access those
    components via a dedicated component tree.
    And you have your event and action handlers there.

    Programming JSF feels more like programming swing than struts, because you usually deal with pages, events which are triggered, components which you can influence from your code etc.

    Also have in mind that you can separate the controller model logic, but you are not forced to do it.
    Programming JSF feels more like programming Swing or Qt, than programming Struts.

    Thats why I said, Struts only people will have hard time to grasp it, because all looks so familiar, but have in mind it is different, you still have your page transitions (although with a saner syntax) but you also have a full blown rich client like programming model and a lot of flexibility in the organisation of your backend mvc patterns.
  160. what component model?[ Go to top ]

    ok. i didn't see any component model in that tutorial though. basically just an <h:inputText> or <h:commandButton> instead of html.

    incidentally, i just was looking through the Oreilly JSF book and happened upon the discussion of Renderers, and there's an example of using java code to write a <form> element to the page. is this what people are doing with JSF?
  161. what component model?[ Go to top ]

    ok. i didn't see any component model in that tutorial though. basically just an <h:inputText> or <h:commandButton> instead of html. incidentally, i just was looking through the Oreilly JSF book and happened upon the discussion of Renderers, and there's an example of using java code to write a <form> element to the page. is this what people are doing with JSF?

    actually if you use jsp as rendering tech (which 99.99% of all people do) the components themselves are hidden in the tags.

    For instance t:inputHTML renders a full blown html editor.
    But the main difference to pure action frameworks is following:

    <t:component valueChangeListener="#{bean.listenerMethod}" binding="#{bean.component" />

    what we have here is a component defined in the frontend with two bindings a value change listener and a component binding in the backend

    what can happen now in the backend once you trigger a lifecycle is

    ... backend class definition code...
    Component component;
    .. setters and getters for the component

    public void onValueChange(ValueChangeEvent evt) {
     component.setVisisble(false);
    }

    for instance
    or getValue or whatever
    see the difference?

    also
    <t:component value="#{bean.value}"/>

    does a struts like autofill of model values
    but the main difference is you normally do not have to take care about the data conversion yourself.
    (So no need for hanving event triggers in normal cases which need a simple submit)

    The fact that you have full access to the components and to a full blown event system with the possibility to alter the page on the fly during the cycle stage is reason enough to compare it more to swing or qt than to struts.


    something like page.add(new Button... is possible in jsf on the backend side.
  162. what component model?[ Go to top ]

    i just read through Rick Hightower's JSF tutorial at http://www-128.ibm.com/developerworks/library/j-jsf1/ There's a controller, a model object, an xml config file, and a jsp page. Um, what's so different about this from a request/action based framework?

    First, read the conclusion... There is a lot less configuration and the configuration is more intuitive (than Struts).

    Second, this was the first article in the series. To see more about components and event handing you need to see the second article (or was it the third).

    It is a good intorduction series (I base this on the many emails I recieved thanking me...yes I am patting myself on the back...someone has to). Keep plugging. There are more ahas to aha.
  163. JSF scalability[ Go to top ]

    Jacob: JSF and scalability, JSF top of the MVC heap


    Jacob states the following:
    "JSF is my benchmark right now (for all around best web MVC solution)... Most people question the scalability of JSF... Is it even an issue when there's only a 4-6% difference?"

    "Everything evolves into some form of what's in place with JSF. Of course, each person has their own ideas as to what the perfect solution is, but JSF is my benchmark right now."

    "All the solutions start out with the idea of having a tree of components that operate on the model. Simple enough. My definition of a component is something that can be evaluated as part of a greater whole or separately. They also participate in all parts of MVC-- rendering, validation, updating, decoding, etc. The important thing is that they can be evaluated independently, and JSF already captures this with it's naked approach to exposing the whole component tree to the developer."

    ...

    "Most people question the scalability of JSF, but again, I haven't seen actual benchmarks that proves it was an unsolvable issue either within the guts of a particular JSF implementation or within the hardware running the application. Is it even an issue when there's only a 4-6% difference? I guess to me, it's not a question of how easy a framework can scale on the hardware, but how easy it can scale use case requirements. Why do you choose full-ORM solutions over straight JDBC? I guess one could reach a point, just like with ORM, where performance starts to degrade. Is it the ORM's fault or is it because the ORM allowed you to easily do overly complicated things? Could the same be applied to component frameworks for all they provide to you?"

    Full blog entry:

    http://weblogs.java.net/blog/jhook/archive/2006/03/reflecting_on_m_1.html

    Pretty Cool Stuff Jacob.

    Rick Hightower (linked in)
    JSF, Spring, and Hibernate training and consulting
  164. JSF and JSP married[ Go to top ]

    "The main theme for the Java Platform, Enterprise Edition (Java EE) 5 is ease of development. The platform's web tier contributes significantly to ease of development in two ways. First, the platform now includes the Java Standard Tag Library (JSTL) and JavaServer Faces technology. Second, all the web-tier technologies offer a set of features that make development of web applications on Java EE much easier. Some of these features are the following:" (java.sun.com)

    A new expression language (EL) syntax that allows deferred evaluation of expressions, enables using expressions to both get and set data and to invoke methods, and facilitates customizing the resolution of a variable or property referenced by an expression

    Support for resource injection through annotations to simplify configuring access to resources and environment data

    Complete alignment of JavaServer Faces technology tags and JavaServer Pages (JSP) software code

    Read the full article here: http://java.sun.com/developer/technicalArticles/J2EE/jsp_21/
  165. "The first article of the "Web Tier to Go With Java EE 5" series summarizes new features in JavaServer Pages (JSP) 2.1 technology. As that article describes, the biggest contribution of JSP technology is better alignment with JavaServer Faces technology, which was accomplished by unifying the two expression languages (ELs). Alignment with the JSP framework is also one of the more important achievements of JavaServer Faces 1.2 technology, developed through JSR 252. In addition to these changes, JavaServer Faces technology contributes a host of other significant ease-of-use features. This article briefly describes the more substantial ones, which include the following:" (java.sun.com)

    Alignment with JSP technology

    Ease-of-use improvements in support for custom messages

    Improved state-saving behavior

    Ability to turn off generation of component client IDs

    New setPropertyActionListener Tag
    See the complete article at: http://java.sun.com/developer/technicalArticles/J2EE/jsf_12/

    Rick Hightower (linked in)
    JSF, Spring, and Hibernate training and Consulting
  166. One of the biggest things in open source is the ability to communicate and interact with other projects, and the main tool for this is by simply showing the source code.

    Another method of interaction is to have a common language, or API, to interact with - people can try different implementations, innovations, and are encouraged to. But, to be able to interact and to compare apples-to-apples, there needs to be a common interaction point. This interaction point is where specifications make this possible.

    The JSF 'spec' has the Sun RI, as well as Myfaces - two different implementations of the same spec and BOTH have success and are learning from each other. While Tapestry, Echo, and (especially) Struts are definately good web tools/frameworks in their own rights and were used as references when building specifications, there is no true apple-to-apple comparison as none of them interact in the same manner (I don't mean to compare template versus logic, just using as references to open source projects).

    There can be bad specifications, yes, but don't immediately bad-mouth a solution because it follows a specification or that *AN IMPLEMENTATION* of the specification may be poor.

    Not all developers can invest time into learning the engineering, design, quirks, and optimization process for every library or tool they use - a developer can learn how to interact with a specification-based tool and be much more productive on whatever it is they are working on.

    I can't speak for Gavin, but I also support JSF, including some of it's quirks. Having tool support, being able to build a business application that interacts with JSF and then testing the Sun RI versus the MyFaces implementation for my business application has huge benefits - I just wish there were more JSF implementations to be able to quickly compare with their own innovations instead of 5-10 different web frameworks that you have to each learn individually to compare and contrast.
  167. One of the biggest things in open source is the ability to communicate and interact with other projects, and the main tool for this is by simply showing the source code.Another method of interaction is to have a common language, or API, to interact with - people can try different implementations, innovations, and are encouraged to. But, to be able to interact and to compare apples-to-apples, there needs to be a common interaction point. This interaction point is where specifications make this possible.The JSF 'spec' has the Sun RI, as well as Myfaces - two different implementations of the same spec and BOTH have success and are learning from each other. While Tapestry, Echo, and (especially) Struts are definately good web tools/frameworks in their own rights and were used as references when building specifications, there is no true apple-to-apple comparison as none of them interact in the same manner (I don't mean to compare template versus logic, just using as references to open source projects).There can be bad specifications, yes, but don't immediately bad-mouth a solution because it follows a specification or that *AN IMPLEMENTATION* of the specification may be poor. Not all developers can invest time into learning the engineering, design, quirks, and optimization process for every library or tool they use - a developer can learn how to interact with a specification-based tool and be much more productive on whatever it is they are working on.I can't speak for Gavin, but I also support JSF, including some of it's quirks. Having tool support, being able to build a business application that interacts with JSF and then testing the Sun RI versus the MyFaces implementation for my business application has huge benefits - I just wish there were more JSF implementations to be able to quickly compare with their own innovations instead of 5-10 different web frameworks that you have to each learn individually to compare and contrast.

    Standards have their place and are important.
    But... All standards are not created equal.
    EJB 1 bad!
    JSF good!

    I think Java has good mix of standards and good Open Source projects.
  168. I just wish there were more JSF implementations to be able to quickly compare with their own innovations instead of 5-10 different web frameworks that you have to each learn individually to compare and contrast.

    That sounds very reasonable. However to this upside there is the downside of specification interchangability. As soon as you are using those innovations you will deviate from the specification and thus bind into a specific implementation for the future of your project. That weakens your argument of having to learn less considerably, even though - admitted - there is a this base of knowledge reuse. But if you look at the kind of improvements that are build on top of JSF today they differ greatly to an extend that it is like using a different framework altogether.

    Another 'problem' with this idea of having a spec with multiple implementations is that it fires the spec writers from having the responsibility to 'finish' it; they can always point to the rest of the world and say 'hey, our job is done, it's up to you guys to do the rest of the work'. Maybe that is too sarcastic and I'm certainly not saying the JCP people don't have their heart in the right place, but I do believe this is can be a side effect of seperating design from implementation too much, just as it can hurt you when you have a seperate team of software architects in your organisation that never get their hands dirty.

    And something else that I had problems with in the past was the fact that different implementations of the same spec can have their own quirks. For example, I have had problems with different JSP implementations (e.g. one had a memory leak in tag lib pooling, causing man weeks of work to track down what the problem was) and just application servers in general. I am surprised so many people blindly follow the thought that the ability to have multiple implementations is a good thing. It might, or it might not.

    Re the title. Anti-spec is anti-open source? Not very convincing. Apples and oranges imo.