Home

News: Shashank Tiwari: JSF in 2007

  1. Shashank Tiwari: JSF in 2007 (59 messages)

    Shashank Tiwari, on OnJava's "JSF in 2007," is asking if JSF will be a leader and a technology of choice for 2007.
    SF came at a time when JSP and similar technologies were popular among web application developers. JSF tried to bring the learnings from desktop client UI development to the web. It initiated the possibility of creation of reusable widgets and controls. It provided a sophisticated event model and provided effective management of the round-trip request response cycle. However, JSF for a while was merely a framework. As implementations and interpretations emerged, the world had moved miles ahead and AJAX had conquered the web2.0 client UI space. Then came the paradigm that AJAX with JSF was not only possible but also a best practice and a way to get the best of both worlds - AJAX and Java together. While many Java developers adopted this paradigm and the followers are growing, its current form with AJAX does appear like a strategy in hindsight and an afterthought. Some frameworks like JBoss Seam and Apache Shale have provided the missing pieces in the JSF puzzle and commercial vendors have come up with multiple implementations and IDE support. However, the Java camp still looks a little confused about the future of the UI technology. I am positive many people would comment aggressively against this remark and many may even try and justify the contrary, but please remember that this is only my opinion and I am an ardent Java fan and I do believe what I am saying here. I would be happy to hear convincing arguments that disprove me. So far whatever I have said it pretty much the past, but what about the future. What would JSF be like in 2007 or will there be a new J* UI technology that would replace it or will Java Applets reincarnates flourish or will we keep guessing about it all year long?
    What do you think about his statement that "the Java camp still looks a little confused about the future of the UI technology"? JSF has a lot of capability for integration; is this a sign that JSF isn't sufficient, or that it's the unifying technology for the future?

    Threaded Messages (59)

  2. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    my primary problem with JSF was templating and reuse so i thought that it will still suck but with the release of Facelets i think my problems gone seam is a really good idea,and a good implementation but it is miss several things: integration with spring(real integration) and its nature make it intrusive,actually very intrusive when u use it in real application apache shale is'nt catching up,however it integrate several good ideas but it still cannot be considered a community standard as struts was,i think that is because it over complicate things(compare facelets with clay)and not providing enough docs(dialogs vs spring web flow)and no real life examples (tiger ext vs seam) ajax in jsf is shaping up and personally i prefer ajax$jsf as it use the existing libraries,so i think it must b part of the standard (along with facelets) ,icefaces is really good but again they over complicate things(direct to dom) which i think unneccserry complex and degrade performance as a conclusion i think JSF took a good shape in 2006 and it must standerdise the best in 2007
  3. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    seam is a really good idea,and a good implementation but it is miss several things: integration with spring(real integration) and its nature make it intrusive,actually very intrusive
    What do you mean that Seam is intrusive? If you mean that it uses contextual bijections to "glue" your code together, I think this a great idea. Sure, some might complain that it doesn't promote a layered-architecture approach, but that doesn't mean the framework enforces such constraint. If you want layers, go ahead and add them. But I'm beginning to agree that for most applications, this might be over-designing. I am happy to cut down the amount of code, and LOC I have to maintain with Seam. After evaluating JSF for about 3 months, it was barely manageable to develop applications with it and I had to have Shale, and Facelets. And after discovering Seam, I swapped it out with Shale and haven't looked back. I also haven't even bothered looking at any other web frameworks. On the other issue with Spring integration, you can inject Spring beans into Seam components currently, but not the other way around. But it is stated in the roadmap, full Spring integration will be provided in the next release. I think many users will find this a welcome feature.
    i think JSF took a good shape in 2006 and it must standerdise the best in 2007
    My prediction is that Seam/JSF will make a lot of noise in 2007.
  4. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    I agree with Joe. And I think the JSF - GWT integration is really interesting and I'd like it if that project took off.
  5. GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best". AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving. The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency. Then came GWT: code in Java, translate to ajax/javascript. Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once. JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine. But a GWT-JSF "merge" is a pointless suggestion.
  6. I understand GWT as a way to have an abstraction over javascript and clientside vs serverside. I did not see that GWT provides stateful components and templating; which is what JSF does. That's why I think they are a good combination. Maybe there's a conflict in clientside state vs serverside state. But I don't think you can offload all state to the client since the client is untrusted; you lose control that way. Btw I'd like to ask all the people who are not interested in the future developments of JSf but want to push other frameworks to go away. Start another thread with a fitting subject. That way people who are interested in JSF can have a fruitful discussion. The endless off-topic framework pushing on the serverside is the main reason I don't visit this site a lot anymore.
  7. Btw I'd like to ask all the people who are not interested in the future developments of JSf but want to push other frameworks to go away. Start another thread with a fitting subject.
    That way people who are interested in JSF can have a fruitful discussion.
    The endless off-topic framework pushing on the serverside is the main reason I don't visit this site a lot anymore.
    These people represent a significant portion of the Java Web community, perhaps the majority. Without them, all JSF forums will become extremely quiet :-)
  8. GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best".

    AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving.

    The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency.

    Then came GWT: code in Java, translate to ajax/javascript.

    Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once.

    JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine.

    But a GWT-JSF "merge" is a pointless suggestion.
    Totally agreed. I would even make it bolder: with a totally client side ajaxy solution there's no need for any fat server side component based web framework such as JSF or whatever, because javascript based high level frameworks such as YUI or GWT are nice! Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion? Ara.
  9. Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion?

    Ara.
    Framework (or better - components) may help you to create that client side code Dmitry http://www.servletsuite.com
  10. GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best".

    AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving.

    The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency.

    Then came GWT: code in Java, translate to ajax/javascript.

    Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once.

    JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine.

    But a GWT-JSF "merge" is a pointless suggestion.


    Totally agreed. I would even make it bolder: with a totally client side ajaxy solution there's no need for any fat server side component based web framework such as JSF or whatever, because javascript based high level frameworks such as YUI or GWT are nice! Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion?

    Ara.
    It's the popular thing to call 'server side' frameworks 'fat'. But why? On what exactly do you base that? And is sending 200kb to your clients, and having 5 client-server calls for what you otherwise would do in one call not 'fat'? It all depends/ the world is not black and white. YUI and GWT are quite different. GWT actually helps with your programming model up to integration with non-UI layers. YUI less so (but it is a nice widget set to be sure). Also, when working with a complex domain model, it is often easier and more efficient (because of locality) to process a whole page at once. Also, with a server side framework you can use any object directly (e.g. your Hibernate objects), while with a framework like GWT, you'll have to use DTOs all over the place. Finally, there are a zillion other features you can compare amongst frameworks, like how well localization is supported, what kind of page composition is supported, whether layout managers work for you (personally I hate them) or you want to work with markup directly, etc, etc. What I'm saying is that GWT is a nice framework, but it has good competition from other frameworks, each having their own pros and conts. You might as well seriously look into that and see what fits your projects best.
  11. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    "Its current form with AJAX does appear like a strategy in hindsight and an afterthought." Hmm ... has this guy ever written a phase listener before? Given an understanding of the JSF phases, it's a pretty easy way to inject an AJAX based solution. I'll cede the point that JSF does not solve everything, but stating that it has some design shortcomings is a bit of a stretch. If anything, JSF gets criticized for being over-designed, not having design afterthoughts ... On the JSF front, I expect more component libraries to emerge in 2007, and also facelets to become mainstream. Once that occurs, the JSF offerings will become pretty enticing, with some very good commercial and open source offerings. However, I still think there is room for GWT as Google does a solid job in executing with their vision. It's hard to ignore Google at anything they do ... Joe Pardi dotJ Software http://www.dotjonline.com
  12. JSF version of Swing[ Go to top ]

    To me the existing built-in JSF components are like AWT and the next big thing could be JSF Swing set.
  13. JSF is too sophisticated[ Go to top ]

    To me, JSF is too sophisticated. After all, it is designed with page-based in mind. If you like Swing, take a look at Echo2, though I'd rather recommend ZK for its amazing simplicity.
  14. Re: JSF is too sophisticated[ Go to top ]

    To me, JSF is too sophisticated.
    thats nicely said and i agree. I have been doing a lot in JSF lately for my last assignment and it sure is an awfull lot better then struts but it is to damn harsh to get stuff done. And what is this dependecy on html? Why is there indeed not yet an SWING or an SWT renderer, because it is not doable. not my 2 cents but just the way it is.
  15. Re: JSF is too sophisticated[ Go to top ]

    I agree. If simplicity and productivity are required, JSF is not the best choice. Rather look at Wicket, and maybe Tapestry. What I was really dismayed about is the taglib API docs. Even the simplest of all tags, f:verbatim, shows what I mean (and this is by far not the worst example): Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content Even after using the tag and reading this for the umpteenth time I still cannot make sense of it..
  16. Re: JSF is too sophisticated[ Go to top ]

    and another example of a typical API idiosyncrasy: the javadocs for the javax.faces.convert.Converter interface state that both methods may receive null values as parameters, and they also prescribe exactly how those values must be handled. This leads to potentially thousand-fold redundant repetition of code like: if(value == null) return null;
  17. Re: JSF is too sophisticated[ Go to top ]

    And what is this dependecy on html? Why is there indeed not yet an SWING or an SWT renderer, because it is not doable. not my 2 cents but just the way it is.
    What dependency on html? JSF can render to all kinds of things - WML, XUL, SVG, even to Telnet. And I would not bet that JSF to Swing or SWT was not doable.
  18. Re: JSF is too sophisticated[ Go to top ]

    I think I will repost my comment from oreillynet. I disagree with the very first Shashank's statement. JSF came definitely at the right time, but it is the wrong product. It has much too high level of abstraction, therefore it is too complex and full of bugs (consequence of complexity). Technologically, it gets beaten by more mature component based frameworks like Tapestry and by more elegantly disigned like Wicket (my current favorite). JSF design goals were to generate income for consultants, tool vendors, component vendors and consultants, not to facilitate the developers job. As for the AJAX - it is actually an orthogonal technology and can be integrated (and is integrated) with any web framework. By the way, the only way to make JSF usable is to use Facelets as ViewHandler, but it is not yet the standard part of JSF. And is also less mature then the other competitors. It looks like a good patch to the bad product.
  19. Re: JSF is too sophisticated[ Go to top ]

    JSF design goals were to generate income for consultants, tool vendors, component vendors and consultants, not to facilitate the developers job.
    Because having a good range of tools, a large and competitive market for components and extensions, and different implementations of JSF competing on features and quality in no way facilitates the developers job, does it?
    As for the AJAX - it is actually an orthogonal technology and can be integrated (and is integrated) with any web framework.
    Yes, but it integrates largely transparently with JSF, because of the high level of abstraction you so dislike.
    By the way, the only way to make JSF usable is to use Facelets as ViewHandler, but it is not yet the standard part of JSF. And is also less mature then the other competitors. It looks like a good patch to the bad product.
    On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.
  20. JSF & Facelets[ Go to top ]

    On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.
    the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale. With Wicket (just to mention one example) you get everything out of the box. I think one problem with JSF is that it was designed by an isolated group without the constant feedback and refinement of a vibrant OSS community. We have almost a decade of investigation in the field of web frameworks behind us, and I am doubtful whether JSF is the candidate to sum all that up to a final conclusion.
  21. Re: JSF & Facelets[ Go to top ]

    On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.

    the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale. With Wicket (just to mention one example) you get everything out of the box.
    You don't get all you get with JSF out of the box. No large component market. No ability to use visual tools. No ability to render to many different client-side architectures. No competing implementations. Also, it is something of an exaggeration to say that you need facelets and other extensions just to make JSF usable. Facelets means I don't have to use JSP, which is nice, but not essential. I have found use of standard JSF along with a good set of components like those from MyFaces is enough to get most things done.
    I think one problem with JSF is that it was designed by an isolated group without the constant feedback and refinement of a vibrant OSS community. We have almost a decade of investigation in the field of web frameworks behind us, and I am doubtful whether JSF is the candidate to sum all that up to a final conclusion.
    Perhaps not, but in many ways (listed above) it far exceeds what many supposedly vibrant OSS communities have come up with. There tends to be a 'if we don't use it, you won't need it' attitude with many OSS projects, which is why web frameworks tend not to consider tooling or extensions, and tend to stick to plain old HTML. JSF should be able to protect investment because of its wide scope and extensibility.
  22. Re: JSF & Facelets[ Go to top ]

    ok, right, figuratively spoken a patch, not literally. To the large components market... I don't need big fat components with 100 configuration parameters, that at the end still don't provide what my customer needs. I want the possibility to easily design my custom components that do exactly what I need! I don't have this possibility with standard JSF, only with Facelets, and it is still less handy to use than Wicket or Tapestry. I do not want different implementations for my project, only one that is good. And I want my application to render to HTML only at the moment. And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.
  23. Re: JSF & Facelets[ Go to top ]

    ok, right, figuratively spoken a patch, not literally.

    To the large components market... I don't need big fat components with 100 configuration parameters, that at the end still don't provide what my customer needs. I want the possibility to easily design my custom components that do exactly what I need! I don't have this possibility with standard JSF, only with Facelets, and it is still less handy to use than Wicket or Tapestry.
    Firstly, of course you have the ability to design your own custom components in standard JSF. Secondly, if you don't like big fat components, choose from the large number of components that are out there that aren't. Why re-invent the wheel when there probably a JSF component out there that does pretty much what you want?
    I do not want different implementations for my project, only one that is good.
    One of the advantages of having different competing implementations is that it allows you to choose the best for your project, and move to another if it doesn't suit you. As an example, a while back I was not satisfied with the state of the JSF RI, so I moved to MyFaces.
    And I want my application to render to HTML only at the moment.
    So only use the HTML rendering.
    And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.
    It is not pure fiction: http://www.nyoug.org/Presentations/2005/20050929jsf.pdf Check out page 37 - it shows the same JSF page designed with ADF components (now open source) rendered well on PalmOS, a standard HTML browser, Telnet and an IM client.
  24. Re: JSF & Facelets[ Go to top ]

    Firstly, of course you have the ability to design your own custom components in standard JSF.
    Of course, it is possible, Steve, but it is pain in the ass, (ever did it yourself?) and everybody knows it, that's why Jacob Hookom invented Facelets!
    Secondly, if you don't like big fat components, choose from the large number of components that are out there that aren't.

    Why re-invent the wheel when there probably a JSF component out there that does pretty much what you want?
    I think this blog just says it all: http://chillenious.wordpress.com/2006/05/12/a-word-about-custom-components/
    One of the advantages of having different competing implementations is that it allows you to choose the best for your project, and move to another if it doesn't suit you.

    As an example, a while back I was not satisfied with the state of the JSF RI, so I moved to MyFaces.
    I don't think that is done very often in reality. Once you choose an implementation, you stick to it.
    And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.


    It is not pure fiction:
    http://www.nyoug.org/Presentations/2005/20050929jsf.pdf

    Check out page 37 - it shows the same JSF page designed with ADF components (now open source) rendered well on PalmOS, a standard HTML browser, Telnet and an IM client.
    Thanks, Steve, an interesting presentation, but I was speaking about a real-world application, not a demo. ;) Usually, an HTML application is pretty different (from the UI point of view) from PalmOS or Telnet one.
  25. Re: JSF & Facelets[ Go to top ]

    Firstly, of course you have the ability to design your own custom components in standard JSF.

    Of course, it is possible, Steve, but it is pain in the ass, (ever did it yourself?) and everybody knows it, that's why Jacob Hookom invented Facelets!
    The difficulty of creating components for JSF is vastly overstated, especially if you only want to create for one rendering type: http://www-128.ibm.com/developerworks/java/library/j-jsf4/ It isn't trivial, but considering the power of JSF's rendering, it is not that bad. As for being 'a pain in the ass' - hey, since when did developers get so lazy? I remember when doing something even slightly technical would have been considered fun :) One of reasons for facelets was to simplify the creation of components, but there were many others, such as the ability to use templates, to use HTML more directly and to remove the need for JSP.
    I think this blog just says it all:
    It is factually wrong in places. Quality JSF components are rarely commercial now. The Oracle ADF components are high quality, and are open source. The same is true of ICEFaces. Of course, having the source, you can customise them.
    I don't think that is done very often in reality. Once you choose an implementation, you stick to it.
    Well, I beg to differ. I have switched implementations of JSF, and I have heard of others who have too.
    Thanks, Steve, an interesting presentation, but I was speaking about a real-world application, not a demo. ;)
    Usually, an HTML application is pretty different (from the UI point of view) from PalmOS or Telnet one.
    So you have gone from saying it is impossible, to wanting a real-world example. OK - Oracle developed the JSF to telnet rendering because specific clients needed it for real life use - it was not simply an academic exercise! Check the oracle forums and you will see that people are really doing this. Of course an HTML application is different from other rendering situations. Although it can be done, it would be rare for someone to expect the same page to render on all those technologies. That is not the point. It means that you can have the same infrastructure, and re-use the same components and even some of the same forms. The claim that multiple rendering is not useful because the same page can't always be presented on all technologies is a surprisingly common "straw man" argument against JSF.
  26. Re: JSF & Facelets[ Go to top ]

    difficulty of creating components for JSF is vastly overstated, especially if you only want to create for one rendering type:

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

    It isn't trivial, but considering the power of JSF's rendering, it is not that bad.

    As for being 'a pain in the ass' - hey, since when did developers get so lazy? I remember when doing something even slightly technical would have been considered fun :)
    I don't know about you Steve, but I have a wife and kids. It may be considered as fun trying for 3 days to get a radio button to work in a table, but... I also need some other kind of fun in my life. Some other people that I know had other problems with JSF, somehow noone was really fascinated. And I don't think it was because they were lazy or stupid. The real reason is as already pointed out, the complexity, the high level of abstraction. Such abstractions necessarily leak and will leak for quite a while. Therefore one still need some good external consultants for JSF projects, like you (assuming you are good) but they are quite expensive (aren't you? ;-)). And they are also not so easy to find, at the moment, some guys just pretend to be good. Ok, the upsides of that level of abstraction are, as you mentioned, the extensibility, the power of JSF's rendering and so on. But I agree with other guys here that the price to pay for some features I might need in the future is rather too high. Now, after thinking about it all, it seems to me that JSF is not only the wrong product but also at the wrong time ;) The alternatives (Wicket, Tapestry) have just the right level of abstraction and let me implement just what I need right now in much shorter time and without the help of expensive consultants, expensive tools and third-party components of doubtful quality.
  27. Re: JSF & Facelets[ Go to top ]

    I don't know about you Steve, but I have a wife and kids. It may be considered as fun trying for 3 days to get a radio button to work in a table, but... I also need some other kind of fun in my life. Some other people that I know had other problems with JSF, somehow noone was really fascinated. And I don't think it was because they were lazy or stupid.
    OK, so I made a silly, throw-away comment. What I was trying to say what that writing a component in pure JSF is not simple, but neither is it that hard. I don't see that a good developer should be put off what what I showed in that article. I agree that things can be tough to get going, but that can be true of any new approach or framework. I would agree that JSF implementations have had their problems, but... What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too? Also, I have a partner and a mortgage. Part of my job is to advise on technology use. Having had experience of so much 'throw-away' software, and technology choices that have tied companies to single vendors and single products, and single technologies. JSF is not a single vendor product, and neither are the components. Its use is increasing significantly, so it will be around long-term. The ability to render to different current (and most likely many future) technologies protects investements in code, tools and skills.
    The real reason is as already pointed out, the complexity, the high level of abstraction. Such abstractions necessarily leak and will leak for quite a while. Therefore one still need some good external consultants for JSF projects, like you (assuming you are good) but they are quite expensive (aren't you? ;-)). And they are also not so easy to find, at the moment, some guys just pretend to be good.
    A whole lot of generalising going on there. I personally know of JSF projects developed by individuals who were novices at JSF - they sat in front of (free) tools and simply designed data-linked forms, and drew up the navigation. So, you don't need expensive external consultants for all JSF projects, and there was no abstraction leak for these developers - the high level of abstraction meant that they could simply sit in front of GUI tool, and start designing.
    Ok, the upsides of that level of abstraction are, as you mentioned, the extensibility, the power of JSF's rendering and so on. But I agree with other guys here that the price to pay for some features I might need in the future is rather too high.
    For me, these aren't features I might need in the future, these are features useful in current projects. I am using the ability to choose between different component sets in JSF right now, and I have use cases for parellel rendering of parts of pages in different technologies in current projects.
    Now, after thinking about it all, it seems to me that JSF is not only the wrong product but also at the wrong time ;)

    The alternatives (Wicket, Tapestry) have just the right level of abstraction and let me implement just what I need right now in much shorter time and without the help of expensive consultants, expensive tools and third-party components of doubtful quality.
    Firstly, that is precisely why I use JSF. It is the right level of abstraction for me, and it allows me to save time and money by using components rather than having to implement things myself. Almost all the tools I know about for JSF are totally free, and I think it is unreasonable to call component sets like ADF and ICEFaces 'of doubtful quality'. That insults a lot of developers who have worked hard to produce good code. There are poor components out there, but also very good sets. A while back, if you had watched me code, you would have heard me cursing at JSF implementations too. But, things have improved, there are good component sets, and things always appear better with experience. I just found the extensibility and flexibility of JSF so appealing that I was prepared to battle through until I found approaches that worked. And now I see that decision paying off.
  28. Re: JSF & Facelets[ Go to top ]

    What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
    I will just address this one and then leave it. With the last statement you imply that development is dull for people who dont get enthusiastic about the same stuff as you. That implication is of course wrong. regards, Chris
  29. Re: JSF & Facelets[ Go to top ]

    What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?

    I will just address this one and then leave it. With the last statement you imply that development is dull for people who dont get enthusiastic about the same stuff as you. That implication is of course wrong.

    regards,
    Chris
    No, you are personalising things too much. It is not about what I, alone, get enthusiastic about. All I am saying is that I remember a time when most developers I worked with and came into contact with were like engineers and scientists, and would enthusiastically investigate and evaluate new ideas simply for the sake of learning more. The multi-rendering of JSF is the kind of thing that I can imagine those developers at least wanting to enthusiastically investigate, even if they turn out not to need them. But I increasingly see new ideas (like JSF multi-rendering) dismissed without even investigation - hand-waved away as 'impossible' or 'not practical' without even research.
  30. Re: JSF & Facelets[ Go to top ]

    I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
    Yes it is dull because it is no fun to develop yet another CRUD application with yet another MVC framework and listen to enthusiastic discussions about wheel reinventions. What is more frustrating is that folks are _truly_ excited about that and do not even realize that they try to reinvent wheels.
  31. Re: JSF & Facelets[ Go to top ]

    I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?


    Yes it is dull because it is no fun to develop yet another CRUD application with yet another MVC framework and listen to enthusiastic discussions about wheel reinventions.

    What is more frustrating is that folks are _truly_ excited about that and do not even realize that they try to reinvent wheels.
    What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework. It has features and capabilities beyond most of the alternatives - a huge amount of extensibility, the ability to visually compose GUIs and to use different renderkits.
  32. Re: JSF & Facelets[ Go to top ]

    What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework...
    It is not MVC framework of course, but it does not make it less of wheel reinvention, and does not make it round wheel. IMO it would be OK if JSF was round wheel, we would embrace it as 'standard' wheel and could be reasonably happy. But unfortunately JSF is kind of irregular octagon.... But there is money to be made by making JSF into a regular hexadecagon :)
  33. Re: JSF & Facelets[ Go to top ]

    What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework...

    It is not MVC framework of course
    Yes, actually, it is.
    but it does not make it less of wheel reinvention, and does not make it round wheel.
    IMO it would be OK if JSF was round wheel, we would embrace it as 'standard' wheel and could be reasonably happy. But unfortunately JSF is kind of irregular octagon....
    But there is money to be made by making JSF into a regular hexadecagon :)
    Nothing like a detailed discussion of technical issues to further the discussion. And that was certainly nothing like a detailed discussion of technical issues...
  34. Re: JSF & Facelets[ Go to top ]

    Hi Steve, I think you are polarising what I believe to be a much needed discussion. The issue is how do you create good OO APIs. There are countless papers out there that support the idea that such APIs are best when they emerge over time from real world applications. This way all the features scratch a real world itch, and uneeded complexity is avoided by not adding infrastrure speculatively for features you think you may need in the future. This is the basis of the refactoring argument and YAGNI. The economics of YAGNI are proven IMO and there are many sources that testify to this on the web. Before responding, this subject is not black and white. To apply Yagni and emergent design well requires judgement. You tend to fall into the trap of two valued thinking. This can limit useful debate IMO. I believe this debate is long overdue and one of the reason why I believe object technology is mostly misunderstood. So please try to see the plurality of ideas here. BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work? Paul.
  35. Re: JSF & Facelets[ Go to top ]

    The issue is how do you create good OO APIs. There are countless papers out there that support the idea that such APIs are best when they emerge over time from real world applications. This way all the features scratch a real world itch, and uneeded complexity is avoided by not adding infrastrure speculatively for features you think you may need in the future. This is the basis of the refactoring argument and YAGNI. The economics of YAGNI are proven IMO and there are many sources that testify to this on the web.

    Before responding, this subject is not black and white. To apply Yagni and emergent design well requires judgement. You tend to fall into the trap of two valued thinking. This can limit useful debate IMO. I believe this debate is long overdue and one of the reason why I believe object technology is mostly misunderstood.

    So please try to see the plurality of ideas here. BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work?

    Paul.
    I simply don't recognise your description of how I am discussing this, and I think the view you present about APIs is one that limits imagination and innovation. Also, if you read back through the discussion, you will see that JSF was designed precisely to scratch real world itches - to open up a true market for web components (an approach that had been proved to be very successful for both developers and vendors in previous environments like VB and Delphi) and to design a server-side UI system that was general, and not tied in to just HTML - and this is a real requirement for many projects. In fact, I have this requirement - this 'itch' for current projects I am working on. And we have already been through the 'yagni' argument, on previous threads. There seems to me to be a common mistake when talking about it, which is to assume that it implies that one should not use a powerful API or product because one might not use all the features. If YAGNI is adopted should be about what the developer has to do in a specific project, not about what the developer uses. Using a rich framework is only an issue if the features of that framework negatively impact the work of the developer. Some would say that the multiple-rendering capabilities of JSF does indeed impact the developer in negative ways because of the extra complexity involved in developing components. I don't think this is much of an impact, but that is one of the things we have been debating here - it is not a 'black and white' matter. In fact, one could even put the case that choosing a web framework that is somewhat easier to develop components in (as against relying on what is now rich sets of free libraries) because you might want to do that at some point is itself going against YAGNI! I am not saying that - but it shows how YAGNI (You Ain't Going To Need It) is not that helpful for this kind of discussion, as it can mean pretty much what you want it to. I have no idea why you think I am not seeing the plurality of ideas, on the contrary, I have been arguing that this is what some others need to do, as illustrated by the frequent comments on threads about JSF that multiple rendering is some sort of hypothetical ideal that is impractical. That suggests a rather closed-minded attitude to new ideas to me.
    BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work?
    That is not the type of rendering to different devices that I am talking about. It is the ability to have the same components (or even the same subset of a page) automatically render to, say, HTML, WML, XUL, or PDF. It is interesting that Wicket has the possibility of doing this as well. It supports my view that this is an exciting and useful feature of server-side GUI frameworks.
  36. Re: JSF & Facelets[ Go to top ]

    It supports my view that this is an exciting and useful feature of server-side GUI frameworks.
    Actually, I am going to make a prediction. I think that in a few years, the ability to render to different presentation technologies will have gone through the following stages: 1. Dismissed by many as not possible. 2. Recognised as possible, but dismissed as irrelevant. 3. Increasingly found to be useful. 4. Considered to be of major benefit by a significant number of developers.
  37. Re: JSF & Facelets[ Go to top ]

    It supports my view that this is an exciting and useful feature of server-side GUI frameworks.


    Actually, I am going to make a prediction. I think that in a few years, the ability to render to different presentation technologies will have gone through the following stages:

    1. Dismissed by many as not possible.
    2. Recognised as possible, but dismissed as irrelevant.
    3. Increasingly found to be useful.
    4. Considered to be of major benefit by a significant number of developers.
    Maybe. But I would be one of those who is dismissing it right now. I think it is important that a framework can easily detect client capabilities and be able to render to different formats. However, unless you're talking about plain non-interactive documents, I don't think there is a big demand for the ability to render the same components to different formats transparently. Imo, you typically want some controlled transformation that you - the user - can easily change on a component level. A good example imo are the frameworks that render for both HTML and e.g. Swing. I have yet to see one that generates truely decent interfaces (decent as in good looking to non techies) for both formats. Note however, that I'm not dismissing the multi-render kit ability as total crap. But it looks like it came with a price. In fact, in the early stages of developing Wicket we discussed whether we wanted separate renderers for components. But we decided against this as we didn't think it was worth the added complexity. It's not JSF's greatest flaw either. Imho there are more serious ones, which all come down to the decision to follow the JSP/ scripting route rather than a pure Java based approach. But that's an opinion you may or may not agree with; good thing there is free choice (though a sad thing that JSF was pushed as a standard upfront rather than letting 'the market' decide). Re the original topic: I think JSF will grow in 2007. Component based development is superior to what - amazingly - still seems today's standard: 'web mvc' (Struts, SpringMVC etc). Though a client-based approach like GWT is a good choice for many projects as well. Good thing about GWT is that it is basically a component based solution as well. Unfortunately, many people seem to have find the new golden hammer in GWT and are turning blind for any disadvantages it might have.
  38. Re: JSF & Facelets[ Go to top ]

    However, unless you're talking about plain non-interactive documents, I don't think there is a big demand for the ability to render the same components to different formats transparently. Imo, you typically want some controlled transformation that you - the user - can easily change on a component level. A good example imo are the frameworks that render for both HTML and e.g. Swing. I have yet to see one that generates truely decent interfaces (decent as in good looking to non techies) for both formats.
    A fair comment, but I have a feeling that the demand will increase. I have a demand, but it is indeed primarily (although not entirely) for non-interactive pages. However, I can see the possibility for significant demand, even for interactive pages, especially with the new UI technologies of Vista.
    Note however, that I'm not dismissing the multi-render kit ability as total crap. But it looks like it came with a price. In fact, in the early stages of developing Wicket we discussed whether we wanted separate renderers for components. But we decided against this as we didn't think it was worth the added complexity.
    I am still not sure exactly what the price is. It certainly adds complexity for the implementors of JSF, but does it really add that much complexity for the developer using JSF? I think, on balance, it doesn't. My long experience of developing using component-based GUIs is that when there is a good supply of components (as is certainly now the case with JSF), then the developer rarely ends up writing components, so does not often face the complexity. Of course, others disagree with me, as they may have worked in projects where components have had to be developed, but I am talking generally. Also, surely having renderers for components does have its advantages - it allows for the addition of functionality at the level of components, which is convenient for both component producers and consumers?
    It's not JSF's greatest flaw either. Imho there are more serious ones, which all come down to the decision to follow the JSP/ scripting route rather than a pure Java based approach. But that's an opinion you may or may not agree with; good thing there is free choice (though a sad thing that JSF was pushed as a standard upfront rather than letting 'the market' decide).
    But the flexibility of JSF means that you don't have to follow the JSP/Scripting route - well, at least not in the way that JSF provides things by default. Facelets is just one example of how you can replace things. I am not quite sure that going down the JSP route (at least for the default use of JSF) was a poor decision - after all, it was a well-established technology. What was certainly poor was the incompatibilities with JSP.
    Re the original topic: I think JSF will grow in 2007. Component based development is superior to what - amazingly - still seems today's standard: 'web mvc' (Struts, SpringMVC etc). Though a client-based approach like GWT is a good choice for many projects as well. Good thing about GWT is that it is basically a component based solution as well. Unfortunately, many people seem to have find the new golden hammer in GWT and are turning blind for any disadvantages it might have.
    I definitely agree with this last point. One thing this thread has done is to convince me that I need to take a much deeper look at Wicket.
  39. Re: JSF & Facelets[ Go to top ]

    My long experience of developing using component-based GUIs is that when there is a good supply of components (as is certainly now the case with JSF), then the developer rarely ends up writing components, so does not often face the complexity. Of course, others disagree with me, as they may have worked in projects where components have had to be developed, but I am talking generally.
    Yes, I am among the others who disagree, just because my experience is different. My customer (a really big one) is very specific about the look and feel of his application's UI. He just doesn't get satisfied with 80 or even 95% complience with his style-guide, he wants all 100%! The standard JSF components might be very good and mighty, but sometimes you have to real struggle to tweak them to fullfill your needs. Somehow it is much easier with Wicket components. Or I just write my own composite components from existing ones because it is so easy. Well, it's just my experience. If your customer always agree with the standard look and feel - good for you.
    One thing this thread has done is to convince me that I need to take a much deeper look at Wicket.
    Good, we on the other hand, will certainly look into JSF. I think I already made some contribution to this damn "radio button in a table" problem. ;-)
  40. Re: JSF & Facelets[ Go to top ]

    Yes, I am among the others who disagree, just because my experience is different. My customer (a really big one) is very specific about the look and feel of his application's UI. He just doesn't get satisfied with 80 or even 95% complience with his style-guide, he wants all 100%! The standard JSF components might be very good and mighty, but sometimes you have to real struggle to tweak them to fullfill your needs. Somehow it is much easier with Wicket components. Or I just write my own composite components from existing ones because it is so easy.
    Well, it's just my experience. If your customer always agree with the standard look and feel - good for you.
    I am kind of surprised that there is this difficulty with components, because I my impression and experience was that just about everything about JSF components is usually customisable to the n'th degree. However, I have almost invariably have worked on (and seen) projects that have not had to conform to an existing detailed style guide, so it is interesting to hear that someone has found this to be an issue.
  41. Re: JSF & Facelets[ Go to top ]

    Below is an example of a grid component that is associated to six different renderers (HTML, CSV, Excel, PDF, RTF, XML). It's not the same as HTML vs. WML, but it gives an illustration of the multi-renderer concept. http://www.dotjonline.com/faces/components/grid/gridScroll.jsf DISCLAIMER: This is only a beta release. Joe Pardi dotJ Software http://www.dotjonline.com
  42. Re: JSF & Facelets[ Go to top ]

    Below is an example of a grid component that is associated to six different renderers (HTML, CSV, Excel, PDF, RTF, XML).

    It's not the same as HTML vs. WML, but it gives an illustration of the multi-renderer concept.

    http://www.dotjonline.com/faces/components/grid/gridScroll.jsf

    DISCLAIMER: This is only a beta release.

    Joe Pardi
    dotJ Software
    http://www.dotjonline.com
    Hi Joe, I don't think anyone is questioning whether or not this is technically possible, but the question in my mind is why you would want to do this in the first place? What is the user problem such a solution addresses? If the issue is users wanting to see the same content formatted in a way suitable for their current viewing device then IMO the ideal solution is one where the client dynamically formats the layout to suite its own needs itself. For example I believe the Opera PDA browser does this with standard HTML, so does IE for PocketPC. Why would a end user want to see the same content with the same layout but rendered using differing presentation technology? To me such a feature seems speculative at best, or an example of over-engineering at worst. My point is that all JSF solutions will bear the added complexity needed to support this feature and that only in a very few instances (if any?) will this feature provide any real business value. This is the argument for YAGNI and keeping things simple. In the rare cases where such a feature adds value, then why not just extend JSF as appropriate? A well designed API should be open for extension. I believe the Wicket author has already pointed out that such functionality could easily be added to Wicket, but that they decided not to provide it out the box for the reasons I describe here. My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less. Paul.
  43. Re: JSF & Facelets[ Go to top ]

    "What is the user problem such a solution addresses?" In the example of the multi-rendered grid, here are two common use cases that I see very frequently: - user wishes to see the information in PDF since the print fidelity of the web browser is not very good. - user wishes to import the data into Excel so that they can manipulate it for their own purposes. Perhaps they wish to add summarizations, or even charts and graphs. "Why would a end user want to see the same content with the same layout but rendered using differing presentation technology?" Although technically you have a good point, I would challenge the notion of depending on the client device for various renderings. If you wait around for IE or Opera to solve this for you, you are going to quickly lose a competetive edge over your competition. It's a hard sell to your customers to tell them that they must wait for IE to provide satisfactory print quality rather than spoiling them with out of the box JSF based PDF. "This is the argument for YAGNI and keeping things simple." I don't disagree with YAGNI, but applying it in the real world is the hard part. It's often just as hard to predict what you ain't going to need. And when you find out you got it wrong, it can be pretty expensive to retrofit a major feature into a solution, especially one with a large customer base using it. Struts is a very good example of that. Its success quickly started to show its design flaws as developers wanted it to do more and more. When they thought they applied the YAGNI principle in Release 1, it bit them in the butt in subsequent releases. "My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less." I don't disagree. Did the designers of JSF over-engineer it or cross a line by providing too much? Only time will tell. Remember, Release 1 is easy ... it's Releases 4, 5, and 6 that show how well the design is. Joe Pardi dotJ Software http://www.dotjonline.com
  44. Re: JSF & Facelets[ Go to top ]

    Hi Joe, I found your response well reasoned and balanced. I left out a lot in my post. I'll respond to what you have said then say why I'm troubled by JSF:
    "What is the user problem such a solution addresses?"

    In the example of the multi-rendered grid, here are two common use cases that I see very frequently:
    - user wishes to see the information in PDF since the print fidelity of the web browser is not very good.
    - user wishes to import the data into Excel so that they can manipulate it for their own purposes. Perhaps they wish to add summarizations, or even charts and graphs.


    This sounds like a valid use case, but I still do not see why multi-renderng needs to be intrinsic to JSF. Here is a link to a Rails Graphing plugin, that does exactly the same thing: http://liquidrail.com/ The difference is the design approach. Rails started off as a simple web application framework with a clean and open design. This has allowed others to create add-ons, easily and cheaply and for the framework to evolve over time. So if you need multi-renderers just plug them in. With JSF everyone gets this feature whether you want it or not. You also get the added complexity too.
    "Why would a end user want to see the same content with the same layout but rendered using differing presentation technology?"

    Although technically you have a good point, I would challenge the notion of depending on the client device for various renderings. If you wait around for IE or Opera to solve this for you, you are going to quickly lose a competetive edge over your competition. It's a hard sell to your customers to tell them that they must wait for IE to provide satisfactory print quality rather than spoiling them with out of the box JSF based PDF.

    I actually agree here, which is why I said that delegating to the client was the ideal approach, after all that is what markup and SGML/XML/HTML etc, is meant to be all about right?
    "This is the argument for YAGNI and keeping things simple."

    I don't disagree with YAGNI, but applying it in the real world is the hard part. It's often just as hard to predict what you ain't going to need. And when you find out you got it wrong, it can be pretty expensive to retrofit a major feature into a solution, especially one with a large customer base using it.
    Here we go. This is the crux of the argument, and why I am troubled by JSF. JSF became a standard before it became a stable, mature and proven web framework. The proof of the pudding is in the eating, and has people have tried to digest JSF they have found the need to replace and modify large parts of it (e.g. templating). My dfficulty with JSF is that I see it as an example of big upfront design. As I said in a previous post good OO API design emerges over time through constant refactorings and responding to real business needs across a number of real world applications. JSF just hasn't gone through this process.
    Struts is a very good example of that. Its success quickly started to show its design flaws as developers wanted it to do more and more. When they thought they applied the YAGNI principle in Release 1, it bit them in the butt in subsequent releases.


    Yes I agree, this makes my point. Struts was another premature standard. It was the simplest thing that could work at the time, but then it became frozen and stopped evolving. YAGNI means adding functionality when you need it. It assumes that the cost of change is low. If you have gone out and built an industry and a whole set of tools based on the current API, then changing things is expensive - this is the problem with premature standardisation not YAGNI.
    "My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less."

    I don't disagree. Did the designers of JSF over-engineer it or cross a line by providing too much? Only time will tell. Remember, Release 1 is easy ... it's Releases 4, 5, and 6 that show how well the design is.

    Joe Pardi
    dotJ Software
    http://www.dotjonline.com
    I believe JSF has missed the boat already. Big upfront design by committee just doesn't work with objects. The web framework landscape moved on through real world experiences whilst the JSF specs were still being solidified to keep the bating Java vendor community happy. There are a number of things I believe that Java frameworks can learn from things like Rails. I think that convention over configuration is a powerful idea, I believe that Wicket has picked up on this. I also think the idea of extending your framework through plug-ins or custom code is very powerful. That way the core framework can remain small and simple. Language features such as mixins in Ruby help with this, but with some imagination it should be possible with Java too. Above all I think the Java community need to get away from premature standardisation of APIs, and let time and experience decide. The way the JCP works seems skewed to serve the needs of vendors who need certainty upfront about what will be the next big Java API, so that they can get their marketing and engineering machines rolling. But OO design just doesn't work that way. Good OO design emerges over time through experience, constant attention and refactorings. I believe this basic mistake about how objects work is why many have moved to open source and to alternative languages like Ruby. Paul.
  45. dotJ Grid Component[ Go to top ]

    http://www.dotjonline.com/faces/components/grid/gridScroll.jsf
    That JSF component does not render properly in Firefox. Wouldn't support for different browsers be common use for multi-rendering? Is the lack of Firefox support in that JSF component the result of an incomplete (or poorly developed) component or is it a common problem with JSF?
  46. Re: JSF & Facelets[ Go to top ]

    hi Steve You have totally missed the point of what I'm saying. I suggest that you read "language in thought and action" by Hawakawa. Two valued thinking versus plural thinking sees the world as black and white, good and bad, and does not allow for anything else in between, such as yagni is a powerful principle when applied well. This more complex analysis allows for a plurality of outcomes beyond two. You seem to struggle with this plurality of possibilities, but alas this is often the case in the real world. With regards to YAGNI and APIs, I am talking about applying the YAGNI principle to the API itself. As for the meaning of YAGNI, the principle is pretty clear to those who practice it. Your last comment on rendering just shows the gulf in our thinking. I am taking the end user perspective, YAGNI in this context, places no limits on product vision and innovation, hence my point that the user problem of rendering to multiple devices does not nessesitate the technical feature in JSF you describe. I think like others I'll give up, but I still belief that this is a useful discussion for the Java community to have. Paul.
  47. Re: JSF & Facelets[ Go to top ]

    hi Steve

    You have totally missed the point of what I'm saying. I suggest that you read "language in thought and action" by Hawakawa. Two valued thinking versus plural thinking sees the world as black and white, good and bad, and does not allow for anything else in between, such as yagni is a powerful principle when applied well. This more complex analysis allows for a plurality of outcomes beyond two. You seem to struggle with this plurality of possibilities, but alas this is often the case in the real world.
    Ouch. I think you are confusing disagreement with your point of view with lack of understanding.
    With regards to YAGNI and APIs, I am talking about applying the YAGNI principle to the API itself.
    Which, as I explained, is of no relevance. Let me try again with an example. Hibernate is a great product that allows very agile development. But, it is also a large product which allows many different approaches. However, it would be absurd to dismiss the use of Hibernate "because there is so much 'You Aint Gonna Need' for this project". Applying YAGNI to APIs is largely inappropriate. All that matters is - will using whatever fraction of the API is required help with development? I would use JSF even if it didn't have rendering to different client types - I like the component approach and I like the extensibility (which I have made use of) and I like the fact that there are different implementations (I have made use of that as well). I have used JSF for projects which were only HTML, and, at least for me, the extra features of JSF added no overhead to that project so, as with Hibernate, to have dismissed JSF because of them would have been unwise.
    As for the meaning of YAGNI, the principle is pretty clear to those who practice it.
    No, it isn't - you are over-simplifying. YAGNI has always been the subject of controversy, with much debate over how dogmatically it should be applied.
    Your last comment on rendering just shows the gulf in our thinking. I am taking the end user perspective, YAGNI in this context, places no limits on product vision and innovation, hence my point that the user problem of rendering to multiple devices does not nessesitate the technical feature in JSF you describe.
    You are misunderstanding here again. JSF is not about rendering to multiple devices, but rendering using different presentation technologies. I have given a specific use case that I need in a current project - rendering to HTML, WML and PDF. To do that with the same component set and API certainly does necessitate technical features as found in JSF. This is not a user problem, it is a developer problem - the developer has to choose the approach that can meet this requirement.
    I think like others I'll give up, but I still belief that this is a useful discussion for the Java community to have.

    Paul.
    It is a discussion that has already been had many times over, and I believe that things are moving the way of component-based systems and flexibility. JSF in particular is showing a substantial take-up. We shall have to see whether or not it dominates long term, but for all its quirks and faults, it will have had a positive influence.
  48. Re: JSF & Facelets[ Go to top ]

    No ability to use visual tools. No ability to render to many different client-side architectures.
    With Wicket you can use any wysiwyg editor, like Dreamweaver. You don't need drag and drop "visual" tools, you don't need a programmer to put your UI together, just a designer. Regarding client-side rendering alternatives, you can even render Swing with sprockets... ----- Gustavo.
  49. Re: JSF & Facelets[ Go to top ]

    No ability to use visual tools. No ability to render to many different client-side architectures.


    With Wicket you can use any wysiwyg editor, like Dreamweaver.
    You don't need drag and drop "visual" tools, you don't need a programmer to put your UI together, just a designer.
    Regarding client-side rendering alternatives, you can even render Swing with sprockets...

    -----
    Gustavo.
    And with JSF+Facelets, you can design a page in an HTML editor if you like. If Wicket can have applications that can transparently (at run-time) detect different client technologies and render appropriately, I would be interested. Is this the case?
  50. Re: JSF & Facelets[ Go to top ]

    The method for achieving this in Wicket would not be the same as in JSF, but you should be able to achieve the same effect relatively easily. Since Wicket allows you to serve different markup files as variants or styles of a page, you could detect the client using our built-in feature for that and then use that information to set the style/variant. The result would be that different clients would receive different markup. I don't know much about JSF, but if I understand the renderers concept correctly, you would do that by providing a component subclass and if you want components to behave differently per-client, you would use the usual UI factory pattern to instantiate the components based on the client. I have not had a need for any of this, but it should work fine. It's straightforward OO programming and all the usual patterns apply.
  51. Re: JSF & Facelets[ Go to top ]

    As far as actually doing multi-client rendering goes, I think Wicket is particularly strong in associating markup variants because a designer can just go rework the page in DreamWeaver for the other device. Where there are small differences in components you can make your component construction conditional. Where there are large differences, you probably would have separate pages anyway. it gets harder for the time being where something like Telnet or WML are concerned because while the architecture supports this kind of thing, the actual component classes for other markup languages would have to be written. At the present time, Wicket only implements HTML markup.
  52. Re: JSF & Facelets[ Go to top ]

    >the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale.
    This is called progress, and it's more than usable IMO once you have all the necessary components. I don't know about you, but I didn't expect everything to be perfect. Sure, JSF in its current state is somewhat disappointing, but I'll be even more disappointed if they didn't include a lot of the enhancements put forth by these additional add-ons in the next revision spec. I'm guessing here, but there was a reason why the JSF spec allows numerous hook-ins, especially with Phase Listeners. Seam, IceFaces, Facelets, Shale, Ajax4jsf, etc. were created to complement the spec. I agree with the previous poster that this is a strength of the JSF spec, and it is well designed. And no, Wicket, nor any other web frameworks comes with ALL the problems solved out of the box.
  53. Re: JSF & Facelets[ Go to top ]

    all this talk about imperfections, remedy by tools and waiting for the next version reminds me of the early days of EJB entity beans. Also then, we already had well-proven solutions to the relational persistence problem (toplink ORM exists since the mid-90s), yet the J2EE spec presented us with something that I will not spend words on. I suffices to say that 6 years later entity beans have finally become what they should have been all the time, by adopting practices from existing OSS (and commercial) products (let me however add that I do think JSF is better than EJB 1 entity beans).
  54. Re: JSF & Facelets[ Go to top ]

    all this talk about imperfections, remedy by tools and waiting for the next version reminds me of the early days of EJB entity beans. Also then, we already had well-proven solutions to the relational persistence problem (toplink ORM exists since the mid-90s), yet the J2EE spec presented us with something that I will not spend words on. I suffices to say that 6 years later entity beans have finally become what they should have been all the time, by adopting practices from existing OSS (and commercial) products (let me however add that I do think JSF is better than EJB 1 entity beans).
    It is nothing like the same. First, JSF does not need tools to remedy things (I never use it with tools), it simply allows the use of tools if desired. It isn't a fix - it is a choice. Secondly, there are no alternative well-proven alternatives that provide the range of multi-rendering that JSF does. There is no 'TopLink' equivalent. In a way, that is good, because JSF could start from scratch, without having to be 'retro-fitted' onto existing solutions. Thirdly, the extension abilities JSF aren't about promising future fixes, they allow all sorts of interesting functionality to be plugged in right now, like Seam. This extensibility was designed in from the start.
  55. JSF multirendering[ Go to top ]

    Steve, your emphasis on multi-rendering and extensibility reminds me of the old JDO vs. EJB3 discussions. Was it not even you who argued in favor of JDOs capability to map objects to different data store architectures? And again, the reply is pretty much the same: I am not willing to pay significantly for a feature that I wont be using in 95% of the cases. Right now, I need a framework that offers optimal support for creating HTML-based web apps. I dont care the least bit for Swing, WAP or any of the other stuff. There are very good solutions out there for this task, and they are what I measure JSF against, period. peace, as Cameron says Christian
  56. Re: JSF multirendering[ Go to top ]

    Steve, your emphasis on multi-rendering and extensibility reminds me of the old JDO vs. EJB3 discussions. Was it not even you who argued in favor of JDOs capability to map objects to different data store architectures?
    Me, and I am happy to defend that point of view. It is why I have stuck with JDO and there have been real advantages in doing so. and I see exciting developments, like JPOX support for XML and db4o. I currently use Kodo, as I have a use case for quering LDAP with JDO.
    And again, the reply is pretty much the same: I am not willing to pay significantly for a feature that I wont be using in 95% of the cases. Right now, I need a framework that offers optimal support for creating HTML-based web apps. I dont care the least bit for Swing, WAP or any of the other stuff.

    There are very good solutions out there for this task, and they are what I measure JSF against, period.

    peace, as Cameron says
    Christian
    You still haven't explained why you think you are paying signficantly. I find the component-based architecture of JSF to be a significant saving of time and money, not a source of hassle, as I make considerable use of existing component libraries and extensions. The only issue with support of different rendering technologies is the complexity of designing components yourself, but if you want to stick with HTML, simply use facelets. JSF with facelets doesn't make you 'pay' - it is rich and simple to use. And, to badly paraphrase Terry Pratchett, things with a probability of a few percent turn up all the time... For me, Java has always been significantly about portability. To use a server-side technology that rendered only HTML would feel wrong to me, just like using a persistence technology that was only relational. To me, this is against the philosophy of Java. But maybe I am just wierd in this regard.
  57. Re: JSF multirendering[ Go to top ]

    For me, Java has always been significantly about portability. To use a server-side technology that rendered only HTML would feel wrong to me, just like using a persistence technology that was only relational. To me, this is against the philosophy of Java. But maybe I am just wierd in this regard.
    Yup. You're weird. The TSS posters who disagree with you represent the gold standard of normalcy.
  58. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    I think these comments are pretty fair. JSF certainly has not been the runaway success Sun was hoping for, uniting the Java web community. Its a complex beastie, which really need good tools support for commercial developers to use. Technologies like Flex are also providing a very strong alternative to JSF and even GWF. If you are looking for an very easy to use Java web framework for commercial developers, take a look at Click Framework. regards Malcolm Edgar http://click.sourceforge.net
  59. Re: Shashank Tiwari: JSF in 2007[ Go to top ]

    I think these comments are pretty fair. JSF certainly has not been the runaway success Sun was hoping for, uniting the Java web community.
    Does anyone ever expect a runaway success? However, there is little doubt that JSF is finally taking off in a big way.
    Its a complex beastie, which really need good tools support for commercial developers to use.
    This wasn't even good FUD a year ago, and it is pretty tired now. The internal complexity of JSF is largely hidden, and it does not and has never needed tool support for use by serious commercial developers. It is amazing how frequently the fact that JSF allows tool use gets twisted into 'JSF needs tools'.
  60. Technologies like Flex are also providing a very strong alternative to JSF and even GWT.
    Flash-based solutions suck because Flash is not an integrated part of any OS or browser. A Flash app running in a browser window is even more ridiculous thing than a crippled 32-bit application running on Windows3.1 through win32s thunk. The splotches of Flash UI, which appear here and there in increasing numbers, do not react properly to keyboard, have fixed size, have fixed-sized fonts, have non-standard widgets, are not integrated with other elements of a page or even with another Flash splotches on the same page, the UI itself is painstakingly slow and juddery, Flash objects are reloaded every time you go forward and back (even Google Finance does that, when you return to a page the stock value graph does not recover the parameters you set before leaving the page). Leave Flash to what it does best -- annoying ads and video clips. For integration with desktop better look in the direction of Microsoft's XAML/Avalon.